Skip to main content
Glama
brentwpeterson

Strety MCP Server

by brentwpeterson
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Strety MCP Server

MCP (Model Context Protocol) server for integrating Strety with Claude Code.

Features

  • Read tools: List todos (filtered by assignee, completion status), get todo details, list people

  • Write tools: Create, update, complete/uncomplete, and delete todos

  • Auto-refresh OAuth tokens

  • Automatic ETag handling for PATCH operations

  • Assignee name resolution (partial match, e.g., "Brent" resolves to full ID)

Related MCP server: mcp-google

Installation

cd /Users/brent/scripts/CB-Workspace/mcp-servers/strety
npm install
npm run build

Configuration

1. Create Strety OAuth App

  1. Go to https://2.strety.com

  2. Navigate to: My Integrations > My Apps

  3. Create new app with:

    • Name: Strety-MCP

    • Redirect URI: https://localhost:8888/callback

    • Scopes: read, write

2. Get OAuth Tokens

See todo/strety-oauth-flow.md for detailed instructions.

Quick version:

# Terminal 1: Start listener
nc -l 8888

# Terminal 2: Open this URL (replace CLIENT_ID)
# https://2.strety.com/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=https://localhost:8888/callback&response_type=code&scope=read+write

# Exchange code for token
curl -X POST "https://2.strety.com/api/v1/oauth/token" \
  -d "grant_type=authorization_code" \
  -d "code=CODE_FROM_CALLBACK" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "redirect_uri=https://localhost:8888/callback"

3. Save Tokens

mkdir -p ~/.mcp-strety
cat > ~/.mcp-strety/token.json << 'EOF'
{
  "access_token": "YOUR_ACCESS_TOKEN",
  "refresh_token": "YOUR_REFRESH_TOKEN",
  "saved_at": "2026-01-27T00:00:00.000Z"
}
EOF

4. Add to Claude Code

Add to ~/.mcp.json or project .mcp.json:

{
  "mcpServers": {
    "strety": {
      "command": "node",
      "args": ["/Users/brent/scripts/CB-Workspace/mcp-servers/strety/dist/index.js"],
      "env": {
        "STRETY_ACCESS_TOKEN": "YOUR_ACCESS_TOKEN",
        "STRETY_REFRESH_TOKEN": "YOUR_REFRESH_TOKEN",
        "STRETY_CLIENT_ID": "YOUR_CLIENT_ID",
        "STRETY_CLIENT_SECRET": "YOUR_CLIENT_SECRET"
      }
    }
  }
}

5. Restart Claude Code

The MCP server loads on Claude Code startup.

Available Tools

Read Tools

Tool

Description

strety_list_todos

List todos with optional filters (assignee, completed status)

strety_get_todo

Get full details of a specific todo

strety_list_people

List all people in the organization

Write Tools

Tool

Description

strety_create_todo

Create a new todo with title, description, assignee, due date, priority

strety_update_todo

Update fields on an existing todo (auto ETag handling)

strety_complete_todo

Mark a todo complete or uncomplete (auto ETag handling)

strety_delete_todo

Permanently delete a todo

Note: Write tools require OAuth tokens with read and write scopes. PATCH operations (update, complete) automatically fetch the required ETag before sending the request.

Token Management

The server handles token refresh automatically:

  1. Tokens are loaded from ~/.mcp-strety/token.json (preferred) or environment variables

  2. When a 401 occurs, the server attempts to refresh using the refresh token

  3. New tokens are saved back to ~/.mcp-strety/token.json

Important: Tokens expire after 2 hours. The auto-refresh handles this, but if the refresh token also expires, you'll need to re-authorize.

API Notes

  • Base URL: https://2.strety.com/api/v1

  • Page size limit: 20 items max per request

  • Rate limit: 10 requests per 10 seconds

  • Pagination: Server fetches up to 50 pages to find all matching todos

Troubleshooting

"Authentication failed" error

  1. Check if tokens are expired

  2. Try refreshing manually (see oauth-flow.md)

  3. If refresh fails, re-authorize completely

"Invalid scope" or 403 when using write tools

The token only has read scope. Re-authorize with read+write scope (see OAuth flow docs).

Todos not showing up

The server paginates through up to 50 pages. If Brent's todos are spread across many pages, they should still be found. Check the assignee filter is correct.

Files

strety/
├── src/index.ts      # Main server code (7 tools)
├── dist/index.js     # Compiled output (gitignored)
├── package.json
├── tsconfig.json
├── .gitignore
├── README.md         # This file
└── docs/
    ├── README.md               # Docs index
    ├── strety-oauth-flow.md    # OAuth documentation
    ├── strety-api-mapping.md   # API endpoint reference
    └── strety-mcp-tools-spec.md # Tool specifications

Development

# Build
npm run build

# Watch mode (if configured)
npm run dev

Available Tools

8 tools
strety_complete_todoA

Mark a todo as complete (or uncomplete it). Handles ETag automatically.

ParametersJSON Schema
NameRequiredDescriptionDefault
todoIdYesThe ID of the todo to complete
uncompleteNoSet to true to mark the todo as NOT complete (reopen it)

TDQS

A3.5/5.0
Behavior3/5

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 adds value by mentioning automatic ETag handling, but does not cover other traits like idempotency, permissions, or side effects beyond toggling completion. This is a minimal but helpful addition.

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 concise sentence that states the primary action first and then adds a notable behavior (ETag handling). No unnecessary words or phrases, making it efficient and easy to parse.

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?

Given the tool's simplicity and lack of output schema, the description adequately conveys the tool's purpose and a key behavior. However, it does not explain the return value or any post-execution state changes beyond 'complete/uncomplete', which could leave some ambiguity for the 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% with both parameters (todoId, uncomplete) described in the input schema. The description does not add any additional meaning or context for these parameters, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Mark a todo as complete (or uncomplete it).' It specifies the verb 'mark' and the resource 'todo', and distinguishes from sibling tools like create, delete, update, and list by focusing solely on completion status.

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?

The description does not provide any guidance on when to use this tool versus alternatives such as 'strety_update_todo'. It fails to mention scenarios where this tool is preferred or excludes conditions, leaving the agent to infer usage without explicit direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

strety_create_todoA

Create a new todo in Strety. Returns the created todo with its ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesTitle of the todo (required)
assigneeNoAssignee name (partial match, e.g., 'Brent' or 'isaac')
due_dateNoDue date in ISO 8601 format (e.g., '2026-02-15')
priorityNoPriority level
descriptionNoDescription text for the todo

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the creation action and return of ID, but does not mention potential side effects, validation rules, or whether assignee or due_date are validated against existing data.

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?

Two sentences, no extraneous words, front-loaded with the core action. Efficient and clear.

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

Completeness4/5

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

Given no output schema, the description explains the return (created todo with ID). Parameters are fully documented in schema. Could mention that assignee supports partial match, but that is in schema. Overall sufficient for a creation tool.

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 coverage is 100%, so the parameter descriptions are already in the schema. The tool description adds no additional meaning beyond stating the overall action.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Create a new todo' and the return value 'Returns the created todo with its ID', which distinguishes it from sibling tools like strety_update_todo or strety_list_todos.

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 on when to use this tool versus alternatives such as strety_update_todo or when prerequisites like existing goals or people are needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

strety_delete_todoA

Permanently delete a todo from Strety. This cannot be undone.

ParametersJSON Schema
NameRequiredDescriptionDefault
todoIdYesThe ID of the todo to delete

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It clearly states the destructive nature ('permanently delete') and the irreversible effect ('cannot be undone'), which is sufficient for a simple delete operation.

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?

Two efficient sentences: the first explains the action, the second emphasizes irreversibility. No unnecessary words; front-loaded with key information.

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 simple delete-by-ID tool with no output schema and full parameter coverage, the description is complete. It explains the action and the irreversible consequence, which is all the agent needs.

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?

The input schema (100% coverage) already describes the todoId parameter. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'permanently delete a todo from Strety', specifying the action and resource. It distinguishes itself from sibling tools (strety_create_todo, strety_update_todo, etc.) as the only delete operation.

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

Usage Guidelines3/5

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

The description implies usage for deleting a todo with an irreversibility warning, but does not provide explicit guidance on when to use it versus alternatives, nor conditions for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

strety_get_todoA

Get full details of a specific todo by its ID

ParametersJSON Schema
NameRequiredDescriptionDefault
todoIdYesThe ID of the todo to retrieve

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior. It indicates a read operation ('Get') but provides no details on authorization, rate limits, or what 'full details' includes. Still, it is not misleading and accurately describes a retrieval action.

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?

One short, front-loaded sentence with no filler. Every word earns its place.

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?

Given the tool's simplicity (one required parameter, no output schema, no annotations), the description is adequate but could be more complete by hinting at the returned structure or any prerequisites. It meets minimum viability but leaves gaps.

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?

The schema already fully describes the single parameter (todoId) with a clear description. The description adds 'by its ID' which reinforces but does not add new meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Get' and resource 'full details of a specific todo' with the parameter 'by its ID', clearly distinguishing from sibling tools like list_todos (which lists multiple) or update_todo (which modifies).

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

Usage Guidelines3/5

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

The description implies usage when you have a specific todo ID and want its details, but provides no explicit guidance on when to use this tool versus alternatives like list_todos for browsing, nor any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

strety_list_goalsA

List goals (rocks) from Strety. Can filter by assignee name and completion status. Returns goals sorted by due date.

ParametersJSON Schema
NameRequiredDescriptionDefault
assigneeNoFilter by assignee name (partial match, e.g., 'Brent' or 'isaac')
maxResultsNoMaximum number of goals to return (default: 50, max: 100)
showCompletedNoInclude completed goals (default: false, only shows open goals)

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It covers output ordering and filter behavior, but lacks explicit statement that it is read-only, does not mention pagination limits (maxResults implies, but not stated clearly), and omits response structure.

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?

Two sentences, zero wasted words. Every part serves a purpose: action, entity, filters, sorting. Ideal conciseness for a tool description.

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?

Given no output schema and low complexity, the description covers usage and sorting but does not specify the fields returned for each goal, which an agent would need to interpret results. Adequate but incomplete.

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?

The input schema has 100% coverage, so the description adds limited value. It mentions filtering by assignee and completion status, but only adds the sorting-by-due-date detail beyond schema. Baseline 3 is appropriate.

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 action ('List goals (rocks)') and mentions filter and sort capabilities. It distinguishes from siblings like strety_list_todos by specifying 'goals' as a distinct concept, though it doesn't explicitly differentiate from other list tools.

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

Usage Guidelines3/5

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

The description indicates when to use the tool (to list goals) and what filters are available, but does not provide explicit guidance on when not to use it or alternatives (e.g., for detailed search or other entity types). Usage is implied rather than prescribed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

strety_list_peopleA

List all people in the Strety organization. Useful for finding assignee names/IDs.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It indicates a read-only operation (list), which is transparent. No side effects are implied. It could mention pagination or limits, but with no parameters, the behavior is straightforward.

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?

Two concise sentences that front-load the purpose and add a usage hint. Every sentence earns its place; no fluff.

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 tool with no parameters and a simple list operation, the description is complete. It explains the action, resource, and practical use. No additional info needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters, and schema coverage is 100%. The description adds no parameter info because there are none, but it clarifies the tool's output usefulness. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all people in the Strety organization', specifying the action and resource. It also adds context about finding assignee names/IDs, which distinguishes it from sibling tools that handle todos and goals.

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 mentions 'useful for finding assignee names/IDs', providing a clear use case. However, it does not explicitly state when not to use it or mention alternative tools, but given the simplicity and unique resource, it's adequate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

strety_list_todosA

List todos from Strety. Can filter by assignee name and completion status. Returns todos sorted by due date.

ParametersJSON Schema
NameRequiredDescriptionDefault
assigneeNoFilter by assignee name (partial match, e.g., 'Brent' or 'isaac')
maxResultsNoMaximum number of todos to return (default: 50, max: 100)
showCompletedNoInclude completed todos (default: false, only shows open todos)

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the tool lists, filters, and sorts, but does not explicitly state it is read-only, mention authentication needs, or describe return format. Basic behavior is covered, but transparency could be improved.

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?

Two sentences, front-loaded with purpose, followed by filters and sorting. No unnecessary words; every sentence adds value. Excellent conciseness.

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

Completeness4/5

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

For a simple tool with no output schema, the description covers key aspects: purpose, filters, sorting. It does not mention return fields or pagination, but the schema handles defaults. It is sufficiently complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all parameters with descriptions (100% coverage). The description adds value by stating the sorting behavior (by due date), which is not in the schema. This enhances understanding beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists todos from Strety, with filtering by assignee and completion status, and sorting by due date. This distinguishes it from siblings like strety_get_todo (single) or strety_list_goals (different resource).

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

Usage Guidelines3/5

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

The description implies use for filtering and listing multiple todos, but does not explicitly state when to use this versus alternatives like strety_get_todo for a single todo or strety_list_goals for goals. No usage exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

strety_update_todoA

Update an existing todo in Strety. Only provide fields you want to change. Handles ETag automatically.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoNew title
todoIdYesThe ID of the todo to update
assigneeNoNew assignee name (partial match)
due_dateNoNew due date in ISO 8601 format (e.g., '2026-02-15')
priorityNoNew priority level
descriptionNoNew description

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It mentions automatic ETag handling, which is a key behavioral detail. It does not describe return value, but for a simple update, this is adequate.

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 extremely concise: two sentences with no fluff. The first sentence immediately states purpose.

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?

Given no output schema, the description could mention what the tool returns. However, the tool has 6 well-documented parameters and the description covers partial update and ETag, so it's fairly complete but has a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so schema documents parameters well. Description adds value by explaining partial update semantics, going beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool updates an existing todo in Strety, uses specific verbs, and distinguishes from siblings like create and delete. It also adds behavioral details on partial updates and ETag handling.

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 advises to provide only fields to change, which is good usage guidance. While it doesn't explicitly compare to alternatives, the sibling tools are distinctly different purposes.

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. 8 tool updatesv0.1.0
    • First observedstrety_complete_todo
    • First observedstrety_create_todo
    • First observedstrety_delete_todo
    • First observedstrety_get_todo
    • First observedstrety_list_goals
    • First observedstrety_list_people
    • First observedstrety_list_todos
    • First observedstrety_update_todo
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 8 tools

Disambiguation5/5

Each tool has a clear and distinct purpose: separate operations for todos (create, read, update, delete, complete), listing goals, and listing people. No ambiguity between tools.

Naming Consistency5/5

All tools follow a consistent 'strety_verb_noun' pattern (e.g., strety_create_todo, strety_list_goals). The naming is predictable and uniform.

Tool Count5/5

With 8 tools, the server covers core functionality without being over- or under-scoped. Each tool serves a necessary role in managing todos and referencing goals and people.

Completeness4/5

The todo operations are complete (CRUD plus completion toggle). However, goals and people are only listable, lacking create/update/delete, which is a minor gap for a full lifecycle.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers