What can you do with this server?

This server exposes Tembo's task and repository management API to MCP clients, though the provided schema reflects the legacy five-tool implementation the README says has been replaced by a generated full-API catalog. * Create tasks (create_task): start background work items in Tembo, specifying an agent (e.g. claudeCode:claude-4-5-sonnet), prompt or description, target branch, related repositories, and whether to queue immediately. * List tasks (list_tasks): browse the organization's tasks with pagination (page, limit 1–100). * Search tasks (search_tasks): find tasks by query string in title or description, with pagination. * List repositories (list_repositories): retrieve the organization's enabled code repositories (useful before creating a task). * Identify the caller (get_current_user): fetch the current authenticated user's information. Note: per the README, the real server now generates one MCP tool per Tembo public API operation (125 operations) in all mode, or a four-tool search_tools/get_tool_schema/call_read_tool/call_write_tool interface when MCP_TOOL_MODE=compact, supporting both stdio (read-only unless --allow-writes) and hosted HTTP with OAuth or bearer keys.

How do I use Tembo MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Tembo MCP Server List the enabled repositories for my organization" 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.

Tembo MCP Server

Official

by tembo

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Tembo MCP

The Model Context Protocol interface to the full Tembo public API, generated from the same OpenAPI contract that drives the SDK. There are no handwritten endpoint tools or SDK-method mappings to maintain.

One package, one generated catalog, two standard transports:

Hosted Streamable HTTP: native Clerk OAuth or a Tembo API key in Authorization: Bearer <key>, with organization-scoped public API permissions. Trusted services can also use the existing agent bearer secret with an explicit organization (see below).
Local stdio: the same tools through @tembo-io/mcp, using your API key. Read-only unless you pass --allow-writes.

Both transports use the official MCP TypeScript SDK v2 serving entries and support the 2026-07-28 protocol plus legacy clients using the 2025-11-25 handshake. The old five-tool implementation is replaced, not maintained as a separate server.

Full API access

By default, each generated API operation is exposed directly as an MCP tool. This lets clients use their native tool discovery and search behavior without an extra MCP-specific search layer.

Set MCP_TOOL_MODE=compact to expose a four-tool compatibility interface instead:

Tool	Purpose
`search_tools`	Search all generated operations by keyword, method, or path; paginate with `offset` and `limit`
`get_tool_schema`	Retrieve an operation's exact name, input schema, method, path, and safety annotations
`call_read_tool`	Execute a discovered read-only operation
`call_write_tool`	Execute a discovered mutating operation after write authorization

For example, search for sessions, inspect a returned operation with get_tool_schema, then supply its exact name and arguments to the appropriate call tool. The server rejects unknown operation names, invalid arguments, and attempts to send a mutation through the read tool. It is not an arbitrary-URL HTTP proxy or a code-execution sandbox.

tools/list paginates direct tools at 50 operations. Both modes reach the same public operations and enforce the same permissions. Tool results include structured { "data": ... } output and a text representation for compatible clients; annotations are hints, not authorization rules.

Live session messages

WebSocket operations cannot run as request/response tools, so they are served as MCP resources instead. Read tembo://sessions/{sessionId}/messages for a session's most recent messages. To follow changes, subscribe to that URI: subscriptions/listen with resourceSubscriptions on the 2026-07-28 protocol, or resources/subscribe on legacy stdio. The server authorizes each subscription with the caller's credentials, holds the API's live WebSocket while the subscription is open, and sends notifications/resources/updated whenever the messages change (including after a reconnect), so the client reads the resource again. At most 10 message URIs are allowed per subscription. Legacy HTTP connections are stateless and cannot receive updates; they can still read the resource.

Related MCP server: openserverless-mcp

Run from source

Requires Node.js 22 or newer.

npm ci
npm run build
node dist/index.js --help

Local stdio

Create an API key in Tembo, then configure your MCP client to launch the built CLI:

{
  "mcpServers": {
    "tembo": {
      "command": "node",
      "args": ["/absolute/path/to/mcp/dist/index.js"],
      "env": {
        "TEMBO_API_KEY": "your-api-key"
      }
    }
  }
}

For local writes, add --allow-writes to args. The API key's server-side permissions still apply. Store the key in your client's secret mechanism where available, not in a committed configuration file. The CLI does not require Clerk settings in stdio mode and reserves stdout for protocol messages.

The package name remains @tembo-io/mcp and the executable remains tembo-mcp. After version 0.2.0 is published, npx -y @tembo-io/mcp@0.2.0 launches this implementation. This PR does not publish that version; the existing registry release must not be mistaken for this code.

Hosted HTTP with Clerk

cp .env.example .env
# Configure the canonical MCP URL, Clerk issuer, and API root.
npm run dev

For production, inject the environment and run npm start or the container. Configure clients with your deployed /mcp URL; the initial 401 response points them to public OAuth protected-resource metadata and requests the organization-selection scope.

Clerk handles client registration, login, consent, and refresh. Clerk must issue JWT OAuth access tokens with the audience claim enabled. The companion API uses the Clerk SDK to verify the token signature, issuer, expiry, and exact environment-specific MCP audience, resolves the selected organization through Clerk userinfo, and checks current membership. Configure MCP_OAUTH_ISSUER with the Clerk issuer; the Tembo API selects the trusted SaaS MCP audience from its deployment environment. The hosted MCP process never stores a shared API key or Clerk secret. There are no custom registration, authorization, or token endpoints here.

Deployment requires the companion API OAuth changes. Configure that API with:

MCP_OAUTH_ISSUER=https://your-instance.clerk.accounts.dev

The API reuses its existing CLERK_SECRET_KEY. Both services must use the same Clerk instance. There is no MCP client-ID allowlist; Clerk manages client registration and user consent. Leaving the API's issuer unset disables OAuth access.

In Clerk, enable Organizations, require PKCE, and configure default OAuth scopes to include user:org:read for organization selection. Enable native Dynamic Client Registration for clients that require it, so users can connect using only the MCP URL. Keep consent enabled. DCR exposes a public registration endpoint: monitor registered clients and understand that client names are not proof of trust. Prefer Clerk's CIMD support for compatible clients where available. See Clerk's guide: https://clerk.com/docs/guides/ai/mcp/connect-mcp-client.

Hosted OAuth grants full public API access within the selected organization, subject to existing user permissions. This includes writes, credential creation, billing changes, deletion, and agent execution. Make that clear during onboarding and consent. There are no custom tembo:* scopes or read-to-write step-up flow. MCP tool approval remains the client's responsibility. No tool automatically retries a failed mutation.

Configuration

Variable	Applies to	Default / meaning
`TEMBO_API_URL`	Both	`https://api.tembo.io`; local deployments must include the API prefix and `/public-api`
`MCP_TOOL_MODE`	Both	`all`; use `compact` for the four-tool compatibility interface
`MCP_OPENAPI_PATH`	Both	Optional local JSON file for development/self-hosting; defaults to the bundled snapshot
`TEMBO_API_KEY`	Stdio	Required; forwarded only to the configured API
`MCP_PUBLIC_URL`	HTTP	Required canonical HTTPS URL ending exactly in `/mcp`; HTTP allowed on loopback
`MCP_OAUTH_ISSUER`	HTTP	Optional Clerk HTTPS issuer origin; unset or empty disables OAuth, not bearer API-key/agent auth
`MCP_ALLOW_INSECURE_HTTP`	HTTP	`false`; permits an explicitly configured non-loopback HTTP `MCP_PUBLIC_URL` only when OAuth is disabled
`MCP_ALLOWED_ORIGINS`	HTTP	Optional comma-separated browser origins, in addition to the server's own origin
`HOST`	HTTP	`127.0.0.1`; container sets `0.0.0.0`
`PORT`	HTTP	`3000`

--transport stdio is the CLI default. --transport http starts the hosted server. --allow-writes is only valid for stdio; HTTP access comes from the caller's Clerk OAuth grant or API key and existing API permissions.

For Tembo's gateway/code mode, add an HTTP connection using existing static-header credentials: Authorization: Bearer <organization-api-key>. No interactive login is needed. Store the key in the connection's secret storage, not in source or tool arguments. The API verifies the key on every request, including revocation, and derives the organization from its key record. Existing internal MCP tools remain separate.

Trusted Tembo services may instead send Authorization: Bearer <existing-agent-secret> together with X-Agent-Org-Id: <organization-id>. The API reuses authAgent, requires a known organization, and retains its organization-scoped database client. The MCP forwards the verified organization only for agent identities. This is privileged service authentication: the shared secret holder can select any known organization. Keep it in trusted backend secret storage, never customer MCP configs, model-visible tool arguments, or untrusted agent sandboxes. Organization-scoped API keys remain the safer choice there. Session tokens are not supported. This adds support only; it does not migrate existing agent connections.

docker build -t tembo-mcp .
docker run --rm --env-file .env -p 3000:3000 tembo-mcp

Self-hosted without Clerk

Run the same HTTP server with MCP_PUBLIC_URL pointing to its canonical /mcp endpoint and TEMBO_API_URL pointing to your own API, including /public-api (and any API prefix). Leave MCP_OAUTH_ISSUER unset or empty. No Clerk account, Clerk secret, OAuth registration, or login is required. The API must include the companion auth-context changes.

HTTPS is recommended. For a private-network installation that intentionally terminates plain HTTP at the MCP process, set MCP_ALLOW_INSECURE_HTTP=true. This opt-in applies only to the public MCP URL and is rejected when OAuth is enabled.

Clients authenticate using an API key, or trusted backend services use the existing agent secret plus X-Agent-Org-Id. Every request is still authenticated by your API. Without an issuer, OAuth discovery endpoints are absent and authentication errors advertise bearer credentials, not a Clerk login. Configuring an issuer enables OAuth alongside those credential types; configure the API with the same issuer and its matching Clerk secret.

This supports a later migration of public-API-backed agent tools; it does not replace internal-only tools or automatically change existing agent connections.

OpenAPI lifecycle

At startup the server reads the versioned openapi/openapi.json bundled in npm and Docker releases, without fetching a live schema. A maintained OpenAPI converter supplies operation metadata and request schemas; name abbreviation is disabled so operation names remain descriptive. Tool names are generated from OpenAPI operation IDs in lowercase kebab case (for example, list-sessions) and validated against the MCP tool-name grammar. Rename an operation in the OpenAPI contract rather than adding a handwritten MCP alias. The official MCP SDK supplies the protocol implementation. A shared adapter normalizes composed object schemas, validates arguments, and dispatches to the generated API client. No per-endpoint adapter is needed.

Startup checks that all public operations generate unique tools, except WebSocket handshakes (operations with a 101 response), which are served as resources. npm run update:openapi fetches the canonical public contract and validates coverage and schemas before updating the snapshot. The update workflow opens or updates a review PR on production-api-deployed repository dispatch, manual invocation on main, or a daily fallback. Unchanged schemas produce no diff. Merge the reviewed snapshot, then release/redeploy MCP; restarting an old release does not change its tools. SDK releases are independent.

Automation requires the public CI GitHub App installed on this repository with contents and pull-request write permissions, CI_PUBLIC_BOT_APP_ID as a repository variable, and CI_PUBLIC_BOT_PRIVATE_KEY as a secret (reuse the SDK/docs bot). The companion monorepo workflow sends production-api-deployed independently to this repo and the SDK after a successful production API rollout. Its existing CI_BOT_APP_ID/CI_BOT_PRIVATE_KEY bot must also be installed on tembo/mcp with contents write permission to send that event. Until both PRs are merged and configured, use the manual schema-update trigger. npm publication remains separate.

The coverage check currently validates 125 public operations against generation and schema compilation. It does not call authenticated customer endpoints or prove that every possible request encoding works. New content types and unusual schemas need serialization regression tests. Internal routes and the existing sandbox-only MCP endpoint are not part of this public contract.

The sync script omits ISO timestamp defaults from response definitions: the public schema evaluates some generated date defaults at fetch time, which otherwise creates a diff on every refresh. Request defaults and actual API responses are unchanged.

Development and checks

npm run typecheck
npm test
npm run check:coverage
npm run build
npm pack --dry-run
npm audit

Tests cover current and legacy HTTP/stdio clients, generated CRUD, composed schemas, compact discovery, scope challenges, argument validation, caller isolation, and offline schema loading. CI checks the committed snapshot, not a changing production schema. Only the schema-update workflow fetches the deployed contract; it never calls customer operations.

Image publishing and deployment

The Publish MCP image workflow runs manually on main or when a GitHub release is published. It requires the source commit to be on main, runs tests, typecheck, schema coverage, and dependency audit, then publishes a Linux amd64 image to the shared ECR repository tembo-mcp. The image tag is the full 40-character MCP commit SHA, not the monorepo commit or a mutable latest tag. Rerunning a publication reuses the existing immutable image. The workflow summary records its tag and digest. Publishing does not deploy anything or publish npm.

Before publishing, configure the release GitHub environment in this repo:

Set ECR_REPO_PREFIX to the shared registry host and ECR_ROLE_ARN to the existing iam-role/ecr-access role ARN, as repository or environment variables.
Have infra create tembo-mcp in the shared registry in us-east-1, with immutable SHA tags and mutable *.mcp environment tags, matching the existing ECR pattern.
Add repo:tembo/mcp:environment:release to the existing ECR role's GitHub OIDC trust. This reuses its shared registry permissions, including tembo-mcp, without ECS deployment permissions. No new role or long-lived AWS credentials are needed.
Protect the release environment with approved branch/tag rules and required reviewers. The separate check job runs without AWS credentials.

The monorepo's manual Deploy MCP workflow accepts environment (dev, staging, or prod) and the image SHA. It reuses deploy-ecs.yaml, including its rollout/stability checks and environment tagging. It uses the existing monorepo environment roles/registry variables and maps dev to the test GitHub environment, staging to staging, and prod to production. Production approval is controlled by that existing GitHub environment; verify its required-reviewer policy before launch. Deployments run only from monorepo main and serialize per environment. The same image can be promoted without rebuilding; rollback selects a previous published SHA.

Infra must provision the following contract before running deployment (no resources are created by these workflows):

Resource	Expected value
ECS clusters	`tembo-use1-{dev,staging,prod}-api`
Service and task-definition family	`tembo-use1-{dev,staging,prod}-mcp`
Container name	`tembo-mcp`
Container port / health path	`3000` / `/health`
Runtime environment	`MCP_PUBLIC_URL`, `MCP_OAUTH_ISSUER`, `TEMBO_API_URL`; image defaults `HOST=0.0.0.0`
Public routing	Host routing to both `/mcp` and `/.well-known/oauth-protected-resource*`; production vanity domain `mcp.tembo.io`

Use each environment's own API URL and Clerk issuer. The MCP container needs no Clerk secret, database credentials, or shared API key. Ensure the task execution role can pull the shared ECR image and deploy/tagging roles can access the new service/repository. Configure TLS, rate limits, logs, and streaming timeouts in infra. Create registry/IAM first, publish an initial image, then provision services using that image and promote through dev, staging, and production.

Schema review and deployment are intentionally separate: API deploy → schema PR → review/merge → publish image → deploy that SHA. No schema-update event can automatically deploy production.

Rollout boundary

The code is the main implementation, not a parallel preview. Merging it does not deploy a host, publish npm, or configure Clerk. Before enabling production, test real client login, org selection, consent denial, refresh, cross-org access, membership removal, and revocation. The API checks Clerk's current grant and organization membership on each request.

Deploy behind HTTPS and edge rate limits. Review upstream redirect policy and egress restrictions, and monitor provider failures without logging credentials or payloads. See SECURITY.md.

Available Tools

5 tools

create_taskC

Create a new task in Tembo. Tasks are work items that Tembo will process in the background.

ParametersJSON Schema

Name	Required	Description
`prompt`	No	Brief description of the task to be performed
`description`	No	Detailed description of the task (alternative to prompt)
`repositories`	No	Array of code repository URLs that this task relates to
`branch`	No	Specific git branch to target for this task
`agent`	No	The agent to use for this task (e.g., "claudeCode:claude-4-5-sonnet")
`queueRightAway`	No	Whether to immediately queue the task for processing

TDQS

C2.9/5.0

Behavior2/5

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 states tasks are 'processed in the background' which hints at asynchronous behavior, but lacks critical details like required permissions, error handling, rate limits, or what 'processing' entails. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding operational behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with two sentences that directly address the tool's purpose. The first sentence states the core action, and the second provides useful context about task nature. There's no wasted verbiage, though it could be slightly more structured with explicit usage guidance.

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

Completeness2/5

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

For a creation tool with 6 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what happens after creation, what the return value might be, error conditions, or system constraints. The background processing mention is helpful but doesn't compensate for the missing behavioral and output information.

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 documents all 6 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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 verb 'create' and the resource 'new task in Tembo', specifying that tasks are work items processed in the background. It distinguishes from sibling tools like list_tasks or search_tasks by focusing on creation rather than retrieval. However, it doesn't explicitly differentiate from other potential creation tools (though none are listed as siblings).

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or compare it to sibling tools like list_tasks or search_tasks. The agent must infer usage solely from the tool name and description without explicit direction.

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

get_current_userB

Get information about the current authenticated user

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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 states it retrieves information, implying a read-only operation, but doesn't specify what information is returned (e.g., user ID, name, permissions), whether it requires authentication, or any rate limits. This leaves significant gaps for a tool that likely involves sensitive user 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?

The description is a single, clear sentence that front-loads the core purpose without unnecessary words. Every part of the sentence earns its place by specifying the action and target, making it efficiently structured.

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

Completeness2/5

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

Given the complexity of user authentication and the lack of annotations and output schema, the description is incomplete. It doesn't explain what user information is returned, authentication requirements, or potential errors, leaving the agent with insufficient context to use the tool effectively in real scenarios.

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 with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here since no parameters exist. Baseline is 4 for 0 parameters, as the description doesn't need to compensate for any gaps.

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 ('Get information') and target resource ('current authenticated user'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_tasks' or 'search_tasks' since those operate on different resources, so it lacks explicit sibling distinction.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication status) or context for selecting it over other user-related tools (though none are listed as siblings), leaving usage entirely implicit.

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

list_repositoriesB

Get a list of enabled code repositories for the organization

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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 states it 'gets a list' but doesn't clarify if this is a read-only operation, what permissions are required, whether it's paginated, or what the output format looks like. This leaves significant gaps for an agent to understand the tool's behavior.

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, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy for an agent to parse quickly.

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 (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavior, usage context, or output, which could be helpful for an agent to operate effectively in a broader workflow.

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 tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't add unnecessary parameter details, earning a high score for not overcomplicating a parameterless tool.

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 verb ('Get') and resource ('list of enabled code repositories for the organization'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_tasks' or 'search_tasks', which prevents 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.

Usage Guidelines2/5

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 like 'list_tasks' or 'search_tasks'. It lacks context about prerequisites, such as whether the user needs specific permissions or when this tool is appropriate compared to other listing tools.

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

list_tasksC

Get a paginated list of tasks for the organization

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of items to return per page (1-100, default 10)
`page`	No	Page number to retrieve (starts from 1, default 1)

TDQS

C2.9/5.0

Behavior2/5

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 pagination, which is useful, but fails to describe critical traits like whether this is a read-only operation, if it requires specific permissions, rate limits, or what the return format includes. This leaves significant gaps in understanding the tool's behavior.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to parse quickly.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It does not explain return values, error conditions, or behavioral nuances like pagination details beyond the basic mention. For a tool with no structured safety or output information, this leaves the agent under-informed.

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% description coverage, clearly documenting the 'limit' and 'page' parameters with details on ranges and defaults. The description does not add any meaning beyond this, as it only mentions 'paginated list' without specifying parameters. This meets the baseline 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 verb ('Get') and resource ('paginated list of tasks for the organization'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'search_tasks', which might offer similar functionality with different filtering or scoping options.

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 provides no guidance on when to use this tool versus alternatives like 'search_tasks' or 'create_task'. It lacks context on prerequisites, such as whether authentication is required or if it's intended for organizational-level access only, leaving the agent without clear usage direction.

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

search_tasksC

Search tasks by query string in title or description

ParametersJSON Schema

Name	Required	Description
`q`	Yes	Search query to find tasks
`limit`	No	Number of items to return per page (1-100, default 10)
`page`	No	Page number to retrieve (starts from 1, default 1)

TDQS

C2.9/5.0

Behavior2/5

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 searching but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what the return format looks like. This is a significant gap for a search tool.

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, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain behavioral traits, return values, or usage context, which are essential for a search tool. The high schema coverage doesn't compensate for these missing elements.

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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as search syntax or examples. Baseline 3 is appropriate when the schema handles parameter documentation.

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 ('Search') and resource ('tasks'), specifying the search scope ('by query string in title or description'). However, it doesn't differentiate from sibling tools like 'list_tasks', which might offer different functionality without search capabilities.

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 provides no guidance on when to use this tool versus alternatives like 'list_tasks' or other siblings. It lacks context about prerequisites, appropriate scenarios, or exclusions, leaving the agent without usage direction.

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.

5 tool updatesv0.1.0Feb 6, 2026
- First observedcreate_task
- First observedget_current_user
- First observedlist_repositories
- First observedlist_tasks
- First observedsearch_tasks

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.4/5.0

Scored 2026-04-18 06:45 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: create_task, get_current_user, list_repositories, list_tasks, and search_tasks target different resources and actions. The descriptions reinforce this separation, making it easy for an agent to select the right tool without confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., create_task, get_current_user, list_repositories, list_tasks, search_tasks). There are no deviations in style or convention, making the set predictable and readable.

Tool Count4/5

With 5 tools, the count is reasonable and well-scoped for a task management server, though it feels slightly thin. Each tool earns its place, but there might be room for additional operations like update_task or delete_task to enhance coverage without being excessive.

Completeness3/5

The tool surface covers core operations like creating, listing, and searching tasks, but has notable gaps in task lifecycle management (e.g., no update_task or delete_task). While agents can work around this for basic workflows, the lack of full CRUD coverage limits completeness for the task management domain.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

mission-controlOAuth
io.github.dinof777
Read and write Mission Control state via MCP — projects, tasks, subtasks, templates, status updates.
Project Management Workplace & Productivity
2
mcp
com.skopik
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Agent Orchestration Knowledge & Memory Search
2
Timequip AOAuth
com.timequip
Manage Timequip projects, tasks, comments, members, and dashboards through MCP.
Project Management Workplace & Productivity
281
ReasonOAuth
io.github.reason-machines
Start and manage Reason cloud coding agents, projects and sessions from any MCP client.
1

Related MCP Servers

Trae MCP Monitor
Monitoring App Automation
n3o-xyz
F
license
Not graded
quality
D
maintenance
Enables monitoring and management of tasks via WebSocket events and authorization requests through MCP tools.
Updated a year ago (2025-07-19 18:37 UTC)
-
openserverless-mcpofficial
Cloud Platforms Developer Tools Security
nuvolaris-extra
A
license
A
quality
B
maintenance
Enables MCP-capable agents to create and invoke OpenServerless endpoints, manage secrets, and configure integrations such as S3, PostgreSQL, Redis, Milvus, and MongoDB.
Updated a month ago (2026-08-30 14:43 UTC)
13
Apache 2.0
Task Tracker MCP
Project Management Workplace & Productivity
triest
F
license
Not graded
quality
B
maintenance
Enables managing tasks through a simple task tracker with REST API and MCP tools for listing, creating, updating, assigning, and deleting tasks.
Updated a month ago (2026-09-03 08:44 UTC)
-
goby-mcpofficial
Project Management Workplace & Productivity
matogen
A
license
A
quality
C
maintenance
Enables MCP clients to list, search, create, update, and comment on Goby tasks, and to manage webhooks, with per-project API key storage.
Updated a month ago (2026-09-12 08:35 UTC)
18
MIT

Tembo MCP

Full API access

Live session messages

Run from source

Local stdio

Hosted HTTP with Clerk

Configuration

Self-hosted without Clerk

OpenAPI lifecycle

Development and checks

Image publishing and deployment

Rollout boundary

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

openserverless-mcpofficial

goby-mcpofficial