t3-code-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools target a distinct resource and action, and the t3_run_* and t3_thread_* groups are largely well separated. The closest ambiguities are t3_run_interrupt vs t3_thread_interrupt and t3_thread_get vs t3_thread_messages, but the descriptions establish clear boundaries.
Naming Consistency4/5
All tools share the t3_ prefix and snake_case, with a mostly predictable resource_action pattern. Minor inconsistencies exist: plural forms like projects_list and pending_actions_list mix with singular forms, and connection_status and thread_messages are noun-like names rather than clear verb-first operations.
Tool Count4/5
At 15 tools, the surface is at the high end but still justifiable given projects, threads, runs, pending actions, and connection inspection each have separate workflows. A few operations could arguably be consolidated, but the set is not bloated enough to be a real usability problem.
Completeness4/5
The main workflow is covered end-to-end: project creation, thread creation and messaging, run waiting and interruption, and pending-action response are all present. Gaps remain around explicit project/thread updates or deletion, though thread archive and thread send act as partial lifecycle operations.
Average 3.8/5 across 15 of 15 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates the operation is safe and non-mutating. The description adds the useful behavioral detail that the result is a 'compact' summary rather than a full thread with all messages, but it does not disclose potential null states, pagination, or other edge behaviors.
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 one tightly packed sentence, starts with the action verb 'Return', and lists exactly what the caller gets. There is no filler or repetition.
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 one-parameter, read-only getter with an output schema present, the description is largely sufficient: it identifies the input indirectly and enumerates the returned data. However, it lacks any pointer on how this summary tool relates to the message/run/pending-action siblings, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single threadId parameter has no schema description and schema coverage is 0%. The description does not mention threadId or clarify its meaning/format beyond what the tool name implies, so it fails to compensate for the lack of 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 names a specific verb and resource: it returns a compact thread summary plus specific components (latest response, active run, pending flags, workspace). This clearly communicates what the tool does, though it does not explicitly contrast itself with siblings like t3_thread_messages or t3_run_get.
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 given about when to use this tool versus alternatives such as t3_thread_messages, t3_run_get, or t3_pending_actions_list. The intended context is only implicit from the listed return fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable behavioral context: message text is bounded by maxChars and truncation is explicitly reported. This goes beyond the annotations and schema.
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 concise and front-loaded, with the core action 'Read paginated thread history' first. The second sentence adds a relevant behavioral detail without fluff, though it is quite brief given the number of parameters involved.
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?
The output schema covers return values and the readOnlyHint covers safety, so the description does not need to repeat those. However, missing guidance on pagination semantics (limit/cursor) and differentiation from sibling tools leaves the description only minimally complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it only meaningfully addresses maxChars. Parameters like limit, cursor, and threadId are left undocumented; their semantics must be inferred from names and schema constraints alone.
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 and resource: 'Read paginated thread history.' This is clear and distinct from simply 'get thread,' though it does not explicitly name sibling tools like t3_thread_get or t3_threads_list. The pagination qualifier adds useful scope.
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 when-to-use or when-not-to-use guidance is provided. The description does not say how this relates to sibling tools such as t3_thread_get or t3_threads_list, so an agent must infer when paginated history is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds context by specifying what is surfaced: pending approval and user-input flags, plus stable action details when the projection exposes them. This goes beyond the annotation by clarifying the nature of the data returned. It does not contradict annotations and provides useful behavioral context.
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 sentence with no fluff. It front-loads the core action and then elaborates with specific details. Every word earns its place, making it concise and well-structured.
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 low complexity (one parameter, read-only) and the presence of an output schema, the description covers the essential purpose. However, it lacks contextual details such as when to use this tool in a workflow, what the response format looks like (though output schema partially covers this), or any edge cases. It is minimally adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for threadId, and the tool description does not explain the parameter's meaning or how it is used. The agent must infer that threadId identifies the thread whose pending actions are listed. This is a significant gap since the description fails to compensate for the missing schema 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 states the resource ('pending approval and user-input flags') and the action ('surface'), which clearly conveys listing pending actions for a thread. It distinguishes from siblings like t3_pending_action_respond by implying a read-only listing rather than an action. The verb 'surface' is slightly less direct than 'list', but the intent is unambiguous.
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 given on when to use this tool versus alternatives. It does not mention that it complements t3_pending_action_respond or when it should be called (e.g., before responding). The context is only implicit from the name and description; no explicit exclusions or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as non-read-only and non-destructive; the description adds the specific non-destructive detail about remote workspace files. However, it does not disclose what archiving does to the thread overall (e.g., whether it becomes unmodifiable or hidden) or the role of the idempotencyKey.
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 sentence with the main action front-loaded and a concise, relevant qualifier. There is no redundancy or unnecessary detail.
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?
An output schema exists, so return values do not need to be described. However, the description lacks key contextual details such as the meaning of 'archive' in this system and the required idempotencyKey behavior, making the definition serviceable but not fully complete for a mutating operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. While threadId is inferable from its name and the tool's purpose, idempotencyKey is a required parameter whose semantics are entirely unexplained, leaving an agent without enough information to supply it correctly.
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 uses a specific verb 'Archive' with a clear resource 'thread' and adds a useful qualifier about preserving remote workspace files. It does not explicitly distinguish from sibling tools, but 'archive' is distinct from interrupt/get/send operations, making the purpose clear.
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 a usage scenario—'archive without deleting files'—but gives no explicit guidance on when to choose this tool over alternatives like t3_thread_interrupt or t3_thread_get. There is no mention of exclusions or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the tool as read-only, so the description's key contribution is the non-obvious caveat: 'A disconnected result is not evidence that the run failed.' This adds useful interpretive context beyond the structured metadata.
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 very short and both sentences carry distinct information: what the tool does and a critical interpretation warning. The use of jargon like 'gateway run handle' and 'T3 state' slightly reduces clarity but not conciseness.
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?
The read-only annotation, output schema, and disconnected-result caveat cover safety and return interpretation reasonably well. What is missing is guidance on how runId relates to a gateway run handle and how this tool differs from t3_run_wait, which an agent would need for confident tool selection.
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?
With 0% schema description coverage alert the only parameter is runId, the phrase 'gateway run handle' adds some semantic color, implying that runId is such a handle. However, the description never explicitly maps runId to that handle or explains how to obtain it, so it only partially compensates for the absent parameter docs.
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 title states the resource ('T3 run status') and the first sentence gives a specific action: reconciling a gateway run handle against T3 state. It is clear enough to identify this as a status-lookup tool, though it does not explicitly distinguish itself from sibling tools like t3_run_wait.
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 explicit guidance is given for when to use this tool versus alternatives such as t3_run_wait or t3_run_interrupt. The disconnected-result caveat is behavioral guidance, not usage routing; the agent is left to infer when this status check is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations say readOnlyHint=true, and the description clarifies that the tool is a non-mutating poll. It adds important context: a timeout is not an error and does not cancel the run. This aligns with annotations. Only minor gap is that it doesn't specify what happens on run completion vs. no change, but the timeout clarification is valuable.
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 two sentences, concise and front-loaded with the primary action. It adds the key behavioral nuance about timeout without redundancy. Could include parameter hints but the brevity is a strength.
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?
There is an output schema (though not shown in detail) which might document return values, so description doesn't need to. The tool is relatively simple with two parameters. The description covers the main purpose and timeout behavior, but misses parameter meanings (since schema coverage is 0%) and doesn't explain 'relevant run change' or how to interpret polling results. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters, but it does not. The runId is only type string with minLength, and timeoutSeconds has defaults and bounds, but the description doesn't define semantics like 'timeoutSeconds' meaning maximum wait time or what 'runId' refers to. The schema provides structural constraints but not meaning.
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 clear purpose: 'Poll for a relevant run change for a bounded interval.' It identifies the resource (run) and action (wait/poll), which is specific enough. However, it does not clarify what constitutes a 'relevant' run change or how it differs from related tools like t3_run_get, which might be used to check status instead of waiting.
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 need to wait for a run change with a timeout. It does not explicitly state when NOT to use it, nor does it mention alternatives like t3_run_get for immediate status checks. The timeout semantics are partially explained (does not cancel run), but there is no guidance on choosing between this and polling manually.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable non-obvious behavior: the interruption is 'journaled' and 'never replayed automatically', which is not captured by the annotations. This helps an agent understand side effects and retry semantics beyond the basic readOnlyHint/destructiveHint flags.
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 two short sentences with no filler. The core action is front-loaded, and the additional journaling/replay detail earns its place by communicating an important behavioral nuance.
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?
The tool has only two simple parameters and an output schema, so the description does not need to explain return values. However, it leaves parameter semantics and tool-selection guidance underspecified, which an agent needs when deciding between t3_run_interrupt and t3_thread_interrupt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain runId or idempotencyKey. The phrase 'one accepted T3 run' hints that runId identifies the target, but the idempotencyKey's role, uniqueness, or replay protection is not addressed.
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 states a specific action ('Request interruption') on a specific resource ('one accepted T3 run'), making the tool's purpose immediately clear. The term 'T3 run' distinguishes it from sibling tools like t3_thread_interrupt, and 'accepted' adds a meaningful scoping constraint.
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 gives no explicit guidance on when to use this tool instead of alternatives such as t3_thread_interrupt. It implies the target must be an accepted run, but does not explain what to do for non-accepted runs or when a different interrupt/wait tool would be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint false, destructiveHint false), so the description carries the burden. It discloses that the operation may not be immediately accepted ('check the mutation status for acceptance') and that the returned branch and worktree reflect the request, indicating asynchronous behavior. This adds value beyond annotations, though it doesn't detail failure modes or retry logic.
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?
Three short sentences, each adding value. The purpose is front-loaded, the conditional for modelSelection is precise, and the behavioral note about mutation status is concise. No filler or redundancy. Excellent structure.
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?
Despite having an output schema, the description omits explanations for most parameters, prerequisites (e.g., project must exist), and the meaning of runtimeMode and interactionMode. With 8 parameters, nested objects, and low schema coverage, the description is not complete enough for an agent to use it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all 8 parameters. It only explains when to supply modelSelection (when the project has no default). It does not clarify title, projectId, idempotencyKey, branch, worktreePath, runtimeMode, or interactionMode. The hint about branch/worktree is vague. This is insufficient given the parameter count and complexity.
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 verb 'create', the resource 'thread', and the context 'in an existing T3 project'. This distinguishes it from sibling tools like t3_thread_get or t3_thread_send, which operate on existing threads. The mention of modelSelection also hints at a specific condition, adding clarity.
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 when to use this tool (to create a thread) and provides a parameter condition ('Supply modelSelection when the project has no default'), but it does not explicitly name alternatives or state exclusions. It doesn't say 'use this instead of X' or when not to use it. The context is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating, non-destructive operation, so the description does not need to restate those. It adds useful behavioral context: a remote workspace is registered rather than cloned, missing directories can be created on request, and an idempotency key is required. There is no contradiction with the annotations.
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?
Three sentences, each earning its place: the core action, an optional behavior, and a concise caveat plus prerequisites. Information is front-loaded and there is no filler or repetition of schema content.
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?
The presence of an output schema reduces the need to describe return values, and key caveats like non-cloning and required scope are included. However, with five parameters and zero schema-level descriptions, leaving the semantics of title, workspaceRoot, and defaultModelSelection implicit makes the definition merely adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It only explains createWorkspaceRootIfMissing and mentions idempotencyKey as a requirement; title, workspaceRoot, and defaultModelSelection are left undocumented, leaving required parameters largely inferred from their names.
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 opens with a specific verb and resource: 'Register a remote workspace as a T3 project.' It clearly distinguishes this registration action from sibling read/list tools such as t3_projects_list, and the explicit 'does not clone a repository' caveat removes ambiguity about what the tool does not do.
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 states prerequisites (orchestration control scope, idempotencyKey) and explains the behavior of createWorkspaceRootIfMissing, but it does not explicitly say when to choose this tool over an alternative. The 'does not clone a repository' note is helpful exclusionary guidance but is not a full usage policy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The sentence 'The gateway forwards the supplied response and does not independently verify human confirmation' adds meaningful behavioral context beyond the annotations, warning agents that the tool is an unchecked forwarding mechanism. Annotations already indicate mutation (readOnlyHint=false) and non-destructiveness, and the description complements them without contradiction.
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 tight sentences, with the core purpose front-loaded and the behavioral caveat kept separate and brief. There is no filler or redundant restatement of the tool name.
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 6-parameter tool with nested objects and an idempotencyKey, the description omits necessary invocation details, particularly how kind selects between decision and answers. The presence of an output schema helps but does not compensate for the missing request-payload semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters, but it only clarifies requestId and kind in broad terms. The important relationship between 'kind' and the payload (decision for approval vs answers for user_input) is not addressed, and idempotencyKey/threadId receive no explanation.
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?
Description clearly states the verb 'Respond' and the resource ('T3 approval or user-input request'), and identifies the stable requestId as the addressing mechanism. This is specific enough to distinguish it from sibling tools like t3_pending_actions_list or t3_run_interrupt.
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 conveys clear context: use this tool to respond to pending approval or user-input requests, not for other thread operations. It does not explicitly name alternatives or when-not-to-use cases, but the purpose is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds behavioral detail beyond them: matching is case-insensitive, and filtering happens before pagination. The filter-before-pagination note is genuinely useful because it tells the agent that limit and cursor operate on the filtered result set rather than the raw project collection. No contradiction with annotations.
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 with zero filler. The core search semantics are front-loaded in the first sentence, and the behavioral note about filter-before-pagination stands as a distinct second sentence. Every word earns its place.
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?
With an output schema present and annotations covering the read-only safety profile, the description covers the main decision-relevant facts: search criteria, case sensitivity, and the filter/pagination ordering. Minor gaps remain: the behavior when 'query' is omitted (returns all projects versus error) is unspecified, and the exact meaning of the 'cursor' parameter is left to its numeric regex pattern. These are small but not fully resolved.
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 description coverage is 0%, so the description carries the burden for parameter meaning. It compensates well for the 'query' parameter by defining what it matches (title, workspace path, or ID substring, case-insensitive), which the bare string type in the schema leaves completely unspecified. However, 'limit' and 'cursor' receive no direct explanation; their semantics must be inferred from the default/maximum/minimum constraints, the regex pattern, and the indirect pagination hint.
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 a specific verb ('Find') and resource ('projects'), and goes well beyond the title by specifying the matching semantics: case-insensitive query against title, workspace path, or ID substring. This active search criteria distinguishes the tool from sibling t3_threads_list (threads, not projects) and t3_project_create (mutation, not enumeration), so an agent can tell them apart without inspecting schemas.
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 usage context is implied rather than stated: an agent can infer this tool is for locating projects by a partial title, path, or ID. However, there is no explicit when-to-use guidance, no mention of alternatives or exclusions, and no routing to siblings such as t3_project_create for creating projects or t3_threads_list for thread-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnly=false and destructive=false. The description adds substantial behavioral context: the call triggers exactly one agent turn, returns after command intent is accepted rather than after completion, rejects busy threads, and has no queueing or steering. The idempotencyKey guidance is also behaviorally relevant. No contradiction with annotations.
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?
Three sentences, no filler. The core action and return behavior are front-loaded, followed by the busy-thread constraint and the idempotency warning. Every sentence adds value.
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?
The required invocation parameters (threadId, message, idempotencyKey) are adequately covered, and an output schema exists so return values need not be described. However, with 7 parameters including nested objects and enums, the optional configuration parameters (runtimeMode, modelSelection, interactionMode, titleSeed) are undocumented, leaving an agent to guess their effect on agent behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only clarifies idempotencyKey ('Never reuse an idempotencyKey for different input') and leaves threadId/message to be inferred from context. The optional parameters runtimeMode, interactionMode, modelSelection, and titleSeed receive no semantic explanation, relying solely on names and enums.
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 a specific verb and resource: 'Send a new or follow-up message to an idle existing thread'. It also states what the tool does beyond sending — 'start one T3 agent turn, and return after command intent is accepted' — which separates it from sibling tools like t3_thread_create or t3_thread_messages.
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?
It gives clear when-to-use context (idle existing threads) and an explicit when-not condition ('Busy threads are rejected'). It also warns against reusing idempotencyKey. However, it does not name any sibling alternatives, such as using t3_thread_create for new threads or t3_run_wait for completion, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description aligns with 'Inspect'. It adds value beyond the annotations by specifying what is inspected (health, freshness, capabilities, scopes), which is useful operational context. It doesn't discuss failure modes or authorization, but for a zero-parameter read-only check 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?
A single, well-structured sentence that front-loads the action ('Inspect') and then enumerates the scope. Every word contributes meaning, with no redundancy or filler.
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?
Given that the tool has zero parameters, readOnly annotations, and an output schema, the description sufficiently covers what the agent needs to know. It doesn't need to explain return values because the output schema handles that. For a simple health-check tool, the description is complete enough to invoke correctly.
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 no parameters, so there is no schema semantics to elaborate. Per the rubric, a zero-parameter tool receives a baseline score of 4. The description naturally has nothing to add about parameter behavior.
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 'Inspect' and clearly enumerates the target (configured T3 environment) and the specific aspects (connection health, freshness, capabilities, scopes). This distinguishes it from the sibling tools, none of which focus on connection health or environment inspection.
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 verb 'Inspect' implies a read-only status-checking use case, but the description does not explicitly state when to use this tool versus others, nor does it provide exclusions or alternatives. Since no sibling tool serves the same status-inspection purpose, the guidance is minimal and left largely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing stale observation rejection, the lack of atomic turn targeting due to session-based interrupts, and the fact that the action does not archive or delete the thread. It also tells the agent how to confirm the result.
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?
Four sentences cover purpose, prerequisite, failure behavior, guarantee caveat, and confirmation step without filler. The essential instruction is front-loaded and every sentence adds value.
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?
With an output schema available)Skip? Need complete. Let's finish.The description covers prerequisites, stale rejection, atomicity limitations, non-destructive scope, and confirmation method. An agent has enough context to decide whether to call this tool and how to invoke it correctly. The only small gap is semantic detail for idempotencyKey, but the overall definition is highly complete for this operation type.Need final answer JSON. Need avoid cutting off. Let's produce final complete JSON. But before final, let's revisit all dimensions and ensure robust justification. We can include full
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?
With 0% schema description coverage, the description compensates for expectedTurnId by tying it to 'latestTurn.turnId' from a prior thread read. threadId is reasonably inferable from the name, but idempotencyKey is left with only its name and schema constraints.
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 states a specific action on a specific resource: 'Request stopping the active turn in a thread.' It adds scope by covering turns 'started outside this gateway' and explicitly disambiguates from archive/delete behavior, so an agent can distinguish it from closely related sibling tools.
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?
It gives a clear precondition and procedure: 'Read the thread first and supply latestTurn.turnId as expectedTurnId,' plus a follow-up check through thread_get. It does not explicitly name alternative tools or state when not to use it, but the operational guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals important behavioral nuances: status values are server-backed, UI-local auto-settle rules are unavailable, open is not synonymous with running, and archive visibility depends on includeArchived. This materially changes how results should be interpreted.
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?
Three dense sentences with no filler. The core search behavior is front-loaded, followed by the most decision-relevant status nuances and the archive-visibility rule. Every sentence earns its place.
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?
The description is highly complete for a read-only list tool, covering search semantics, status behavior, and archive visibility. It omits pagination behavior involving limit and cursor, but the output schema and parameter defaults reduce the risk of incorrect invocation.
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?
With 0% schema description coverage, the description explains the meaning of query (case-insensitive substring), status (server-backed enum values), includeArchived (visibility control), and projectId (filtering by project). It does not explain limit or cursor, though these are conventional pagination fields inferable from 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 names a specific verb ('Find') and resource ('threads') and specifies the search dimensions: project and case-insensitive title, branch, or ID substring. It clearly differentiates the list operation from sibling tools like t3_thread_get or t3_thread_archive.
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 practical guidance for when to rely on status filters and how includeArchived behaves when no status is supplied. It does not explicitly compare against alternatives, but the semantics are specific enough that an agent can use the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

t3-code-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![t3-code-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/MaximilianMauroner/t3code-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MaximilianMauroner/t3code-mcp)

Score Badge

Copy to your README.md:

[![t3-code-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/MaximilianMauroner/t3code-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MaximilianMauroner/t3code-mcp)