t3code-mcp

by ThomasCrund

Overview Schema Related Servers Score Discussions

TypeScript

Local

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 (threads, projects, approvals), but a few could be confused: interrupt_thread vs. stop_thread both halt work, and wait_for_turn vs. wait_for_change both block on state changes. The descriptions clarify these enough to avoid real misselection.
Naming Consistency3/5
All names use snake_case, but the pattern is mixed: most are verb_noun (list_threads, send_message, get_thread), yet several are noun-only (pending_actions, thread_digest, workspace_digest) or use a prefix (t3_status). This inconsistency makes predicting tool names harder than a uniform verb_noun convention.
Tool Count3/5
At 19 tools, the set is at the heavy end of the typical range. Each tool appears to have a genuine purpose, but some can feel redundant (two wait tools, two digest tools), making the surface larger than strictly necessary.
Completeness4/5
The tool surface covers the full thread lifecycle well: create, list, read, message, interrupt, stop, archive, unarchive, and title threads, plus approval handling and status monitoring. Minor gaps include no permanent thread deletion and limited project management, but these are not core to the server's apparent purpose.
Average 4.1/5 across 19 of 19 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the thread and session survive and that a new message can be sent afterwards, which is a key consequence. However, it does not address error conditions (e.g., no running turn), required permissions, or idempotency, leaving gaps.
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 and gets directly to the point. It front-loads the action and provides essential consequences without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, the description covers the main functionality and the survival of the thread/session. However, it lacks information about error behavior and does not clarify how this tool relates to the sibling 'stop_thread', which is important contextual information.
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 input schema contains one required string 'threadId' with no description, and the description makes no mention of parameters. The threadId is implied by the tool name and text, but the description adds no explicit semantic detail to compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool interrupts the agent's current turn on a thread, using the analogy 'like pressing stop'. It further specifies that the thread and session survive, which clarifies the scope. However, it does not explicitly distinguish this from the sibling tool 'stop_thread', so it falls short of full differentiation.
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 provides a clear use case: interrupt a running turn, then send a new message afterwards. It implies this is a soft stop, but it does not mention when to choose this over 'stop_thread' or other alternatives. There are no explicit exclusions or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the outcome (moving to active list) but does not disclose behavior such as prerequisites (thread must exist and be archived), side effects, failure modes, or return values. The description is too minimal to provide adequate transparency.
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 a single sentence of eight words, with no wasted words. It is front-loaded and efficient, though it could be slightly expanded to include critical context without becoming verbose.
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, no output schema, and minimal parameter documentation, the description is not complete enough. It covers the primary purpose but omits usage guidance, parameter meaning, and behavioral details, leaving an agent under-informed for correct invocation and error handling.
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 one parameter (threadId) with no description, and schema description coverage is 0%. The tool description does not mention this parameter at all, failing to compensate for the lack of schema-level documentation. Even though the parameter name is self-evident, the description adds no value in explaining its format, source, or 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 'Bring an archived thread back to the active list' uses a specific verb (bring back) and resource (archived thread), clearly distinguishing it from the sibling tool archive_thread. It fully states the tool's function with no ambiguity.
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 implies when to use the tool: when you have an archived thread that should be active again. It does not explicitly mention alternatives or exclusions, but the context and sibling tools make the use case clear. The inverse relationship with archive_thread is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic operation and gives an example, but does not disclose any behavioral traits such as whether the operation is a mutation, permissions required, or behavior on invalid input. For a rename tool, this is insufficient.
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 that is concise and front-loaded. The parenthetical example adds helpful context without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter rename tool, the description is adequate but not complete. It lacks details about return values, error conditions, and any constraints on the title. Given no annotations or output schema, more context 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 schema has 0% description coverage for parameters. The description mentions 'title' in the example but does not explain either parameter's meaning or constraints beyond the schema's basic types and minLength. The description adds minimal value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set a thread's title' with a specific verb and resource. It is distinct from sibling tools like archive_thread or send_message, and the example clarifies the intended use case.
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 provides clear context for when to use this tool (renaming a thread), and even gives a voice-interaction example. However, it does not explicitly mention alternatives or when not to use it, though the purpose is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose side effects. It describes the action and the answers format but does not mention whether answering completes the request, whether it is reversible, or any permission requirements. As a mutation tool, this lack of consequence disclosure is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and immediately follows with operational details. No redundant phrases; every sentence has a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations. The description provides the essential steps for invoking the tool, but it does not describe the return value or post-answer effects. It also does not differentiate from respond_to_approval beyond the resource name, leaving the tool usable but not fully transparent.
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?
Only 33% of parameters have schema descriptions. The description adds value by explaining that answers is an object keyed by question id and that requestId comes from pending_actions/get_thread, but threadId remains unexplained. This partially compensates for the low schema coverage.
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 'Answer' and a specific resource 'pending user-input request', clarifying that it handles agent questions with options or free text. This clearly distinguishes it from the sibling respond_to_approval by specifying the type of request.
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 states the context for use: 'Answer a pending user-input request', and instructs to get requestId and question structure from pending_actions or get_thread. It does not explicitly exclude approval requests, but the resource type is clear enough to imply when to use this tool.
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?
With no annotations, the description carries the full burden. It discloses important behavior: case-insensitive substring matching on each word, and that it searches active and archived threads. However, it does not mention return format, ordering, pagination, or any potential side effects. This is a moderate level of transparency 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 concise and front-loaded: the first sentence states the primary use, the second adds scope. No wasted words, and the key matching semantics are included without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description covers the search criteria and scope but omits what the response looks like (e.g., list of threads, thread IDs, full objects). Given sibling tools like list_threads likely return threads, an agent might infer this, but it's not explicitly stated. The core search behavior is well described, but the return structure is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only limit is described with 'Default 10'). The tool description compensates by explaining the query parameter's meaning: words matched against title, project name, or branch. Limit is not elaborated beyond its schema default, but its purpose is reasonably inferable from the parameter name and the 'search' context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find threads by words from the title, project name, or branch' with specific matching behavior. It differentiates from siblings like list_threads (which lists all) and get_thread (which retrieves a specific thread) by focusing on keyword-based search.
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 the tool (when you need to search threads by words) but does not explicitly compare with alternatives like list_threads or provide any exclusions. It gives clear context about scope (active and archived) but lacks explicit when-to-use vs when-not-to-use guidance.
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?
With no annotations, the description carries the full burden. It transparently discloses that markdown/code is stripped and lists what the digest contains. However, it does not explicitly state that the operation is read-only or describe any side effects, error behavior, or permission requirements. The read-only nature is implied by 'digest' but not stated, leaving a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with the core purpose. The first sentence defines the output and contents, the second adds the target use case. 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?
For a simple read-only tool with no output schema, the description provides a good picture of the returned content (thread status, last agent message, pending items) and the TTS focus. However, it omits how maxReplyChars affects the result and doesn't explicitly confirm read-only behavior, so it is not fully 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?
The description does not explain the parameters. threadId is implicitly 'one thread' but not explicitly described, and maxReplyChars is not mentioned at all. Schema coverage is only 50% (threadId has no description; maxReplyChars has only 'Default 800'), and the description fails to compensate by clarifying what maxReplyChars controls (e.g., output length for TTS) or how it affects the digest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: producing a TTS-friendly plain-language digest of a thread, including what it's doing, the agent's last message (with markdown/code stripped), and pending items. It differentiates from siblings like get_thread (raw thread) and thread_status (status-only) by emphasizing the digest format and read-aloud design.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: 'Designed to be read aloud by a voice assistant' and 'TTS-friendly' indicate that this is for spoken consumption. It implies usage when a summarized, speech-optimized version is needed, but it does not explicitly state exclusions or name alternative tools. This matches 'clear context, no exclusions'.
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?
Without annotations, the description carries the full burden. It goes beyond the title by disclosing that archiving hides the thread from the active list and is reversible. This provides important safety-relevant context (non-destructive, can be undone) even though it does not mention permissions or return values, which are less critical for such a simple operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the verb. Every word serves a purpose: 'Archive a thread' states the action, while the parenthetical adds the crucial behavioral details of hiding and reversibility without bloat.
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 tool with one parameter and no output schema, the description covers the essential aspects: the action, its effect, and reversibility. It does not describe the return value or edge cases, but the tool's simplicity makes those omissions less impactful. The description is sufficient for an agent to understand the core behavior.
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 has a single required parameter, 'threadId', with no description. The tool description does not explicitly explain the parameter, but the phrase 'Archive a thread' implicitly ties threadId to the thread being archived, and the field name is self-explanatory. Since schema coverage is 0%, the description could have added more detail, but the single well-named parameter reduces ambiguity.
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 ('Archive a thread') and immediately clarifies the effect ('hides it from the active list') and a key characteristic ('reversible'). This clearly distinguishes the tool from sibling operations like unarchive_thread, which restores archived threads.
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 the usage context: use this tool when you want to hide a thread from the active list, and the note 'reversible' hints that the action can be undone. However, it does not explicitly mention the alternative 'unarchive_thread' or state when not to use this tool, so the guidance remains implicit rather than clearly contrasted with siblings.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains that the provider process is shut down, the thread and history persist, and a new session auto-starts. This is sufficient to understand the side effects, though it does not address permissions or edge cases like in-flight messages.
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 only two sentences long and immediately states the action. Each sentence contributes distinct behavioral information without redundancy, making it both concise and well-structured.
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 tool with a single simple parameter and no output schema, the description covers the essential behavioral contract: what stops, what persists, and what happens next. It lacks additional context like when to prefer this over interrupt_thread, but given the tool's simplicity, it is reasonably 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 must compensate for parameter meaning. It only refers to 'a thread' generically and does not elaborate on what threadId should represent or how to obtain it. The parameter name is self-explanatory, but the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'shut down' and clearly identifies the resource ('provider process attached to a thread'). It also distinguishes itself from potential sibling tools by stating that the thread and history remain and a new session starts automatically, making the tool's purpose unambiguous.
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 provides clear context for when to use the tool (to stop a thread's agent session) and its consequence (a new session starts on the next message). However, it does not explicitly mention alternatives like interrupt_thread or state when not to use it, falling short of full exclusionary guidance.
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?
With no annotations, the description carries the burden. It reveals it returns messages, session status, pending requests with requestIds needed for responses, and an activity overview, plus mentions pagination behavior. It implies read-only nature via 'Read' but does not describe side effects or error conditions.
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, front-loaded with the core purpose, and wastes no words. It efficiently covers the tool's functionality and pagination hint.
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?
Without an output schema, the description adequately outlines the response content (messages, session status, pending requests, activity) and pagination. It stops short of detailing the exact structure of each element, but this is sufficient for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all four parameters, so the baseline is 3. The description adds minimal meaning beyond the schema, only contextualizing turnLimit as 'last N turns' and beforeCursor for pagination, which the schema already explains.
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 it reads a thread's recent conversation and lists specific content: messages, session status, pending requests with requestIds, and activity overview. This distinguishes it from siblings like list_threads or t3_status by focusing on the thread conversation itself.
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 provides clear context for using this tool to fetch a thread's conversation, including pagination via beforeCursor. It doesn't explicitly mention when not to use it or point to alternatives, but the context is unmistakable.
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?
With no annotations, the description must carry the full burden of disclosing behavior. It explains the content and payload (requestIds), but does not explicitly state whether this is a read-only operation or any other safety/side-effect characteristics. For an inbox-like tool, this is a notable omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core concept 'Cross-thread inbox', and no wasted words. Every sentence serves a purpose: defining the tool and linking to related tools.
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 0-parameter tool with no output schema, the description does a good job of explaining what is returned and how to use it with sibling tools. It could be more explicit about the response format or grouping, but it's sufficient for an agent to invoke it and inspect the response.
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 zero parameters, so the baseline is 4. The description adds value by mentioning requestIds for sibling tools, but this isn't about the tool's own parameters. Thus it meets the baseline without needing further clarification.
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 identifies the tool as a 'Cross-thread inbox' listing every thread blocked on the human, with specific item types (approvals, questions, plans, errored sessions). This distinguishes it from siblings like list_threads or get_thread, which focus on threads generally or individually.
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 provides clear context for when to use it—when there are pending actions requiring human attention—and even mentions the requestIds needed by respond_to_approval / respond_to_user_input, showing a usage chain. However, it doesn't explicitly say when not to use it or contrast with alternatives.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions checking auth and summarizing project/thread status, implying a read-only health check, but does not explicitly state there are no side effects or describe the exact return structure. This is adequate but not highly detailed.
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 two-sentence description is front-loaded: the first sentence defines the tool's purpose and output, the second gives usage context. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides a reasonable summary of what it returns (running status, auth, project/thread counts) and when to use it. It could be more specific about the output format, but for a simple status tool it is sufficiently complete.
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 zero parameters, so the baseline is 4. The description appropriately says nothing about parameters since there is nothing to configure. No additional semantic explanation is needed.
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 explicitly states what the tool does: check the local T3 Code server's running status, auth, and project/thread summaries. This is a specific verb+resource with a clear scope that distinguishes it from sibling tools like list_projects or list_threads, which focus on individual data retrieval.
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 phrase 'Use this first if anything else fails' gives direct guidance on when to invoke this tool as a first-line diagnostic. While it doesn't enumerate alternatives or explicitly state when not to use it, the context is clear enough for an agent to understand its role in troubleshooting.
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?
With no annotations, the description carries the full burden. It discloses the long-poll blocking behavior, the return of changed threads with old and new state, and the timeout condition. It does not specify exact behavior on timeout (e.g., empty list) but covers the main behavioral aspects well.
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 concise: two sentences that each earn their place. The first explains the mechanics; the second adds the real-world use case. No wasted words or redundant details.
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 tool with no output schema or annotations, this description is quite complete. It covers the wait condition, return value, timeout, and a use case. It could mention what happens on timeout explicitly, but the timeout behavior is implied and the description is sufficiently informative for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter timeoutSeconds is fully described in the schema (including range and default), so schema coverage is 100%. The description mentions timeout only generally and does not add semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: long-poll the workspace until any thread changes attention state or timeout. It gives specific examples (turn finishes, approval appears, error occurs) and distinguishes itself from siblings like wait_for_turn by focusing on 'any thread'.
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?
A clear use case is provided ('Lets a voice loop stay silent until something actually happens'), which implies when to use this tool. However, it does not explicitly name alternatives or exclusions, though the 'any thread' phrasing contrasts with wait_for_turn.
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?
With no annotations, the description carries the burden. It discloses the format (one-line per thread, TTS-friendly spoken field plus structured rows), the ordering (attention first, then working, then finished), and scope (across all projects). It doesn't mention the sinceHours parameter's effect, but that's in schema. No side effects implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no fluff. Every word contributes to understanding the tool's function and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a simple read-only briefing with one optional param, the description gives enough context: scope, ordering, return format. No output schema, so it partially describes the output. It doesn't mention specifics like pagination or limits, but that's acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (sinceHours documented), so baseline 3. The description doesn't mention the parameter, but doesn't need to as schema fully documents it. No additional semantics added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a one-line-per-thread briefing across all projects, explicitly positioning it as the answer to 'what are my agents doing.' This distinguishes it from thread_digest, which is per-thread, and other 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?
The description implies usage for workspace-wide status overview, with ordered sections for attention/working/finished. It doesn't explicitly name alternatives but the context makes it clear when to use this tool. A slight gap is no explicit 'when not to use'.
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?
No annotations are provided, so the description carries the burden. It discloses sort order ('most recently updated first'), filters (project, attention, archived), and row content (attention state), which is meaningful behavioral context for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main action, with no redundant 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 description lacks a complete picture of returned rows: it mentions attention state but not other likely fields like thread ID, title, project, or timestamp. Without an output schema, this gap limits an agent's ability to predict the tool's output fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds semantic meaning to the 'attention' parameter by explaining that the attention state indicates 'what, if anything, it needs from the human,' which deepens understanding of the enum values beyond the schema's minimal description.
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 'List agent threads in T3 Code, most recently updated first' with a specific verb ('List'), resource ('agent threads'), scope ('T3 Code'), and sort order, clearly distinguishing it from siblings like get_thread or search_threads.
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 implies usage for checking threads by attention state ('Each row includes the thread's attention state — what, if anything, it needs from the human'), but does not explicitly contrast with alternatives like search_threads or pending_actions.
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?
With no annotations provided, the description carries the full transparency burden. It discloses key behavioral traits: the thread runs in the project workspace (no worktree isolation), model selection defaults, and runtimeMode defaults to 'approval-required' (safest) with a recommendation for 'full-access' for autonomous work. This goes beyond schema details by explaining the default behavior and safety posture, though it does not explicitly mention side effects like agent autonomy or asynchronous execution.
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 wasted words. The first sentence states the primary purpose, the second adds a workspace-specific constraint, and the third covers default behaviors. Each sentence earns its place and the most critical information (what it does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, creates asynchronous work), the description covers the essential launch context: project/thread creation, first message, default model, runtime mode options, and the workspace isolation limitation. It does not describe the return value or how to monitor the resulting thread, but with no output schema and sibling tools like thread_digest and wait_for_change, this is a reasonable gap. Overall, it is complete enough for an agent to successfully invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%), so the baseline is 3. The description adds value by explaining the model fallback chain ('defaults to project's default, falling back to most recent thread's model') and the runtimeMode default semantics (approval-required safest, full-access for autonomous). This enriches the schema's bare enumerations and clarifies the actual behavior for model and runtimeMode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new agent thread in a project and send its first message, starting the agent.' This specific verb-resource pair ('create thread') plus the initiating action ('starting the agent') distinguishes it from sibling tools like send_message (which targets existing threads) and list_threads (which only lists). The scope is explicit (project workspace, not UI).
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 implies when to use this tool: when starting a new agent thread in a project with an initial message. It provides contextual details like 'worktree isolation is only available from the T3 UI,' which indicates a limitation compared to the UI. However, it does not explicitly name alternative tools (e.g., send_message for existing threads) or state when not to use it, so it earns a 4 rather than 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?
With no annotations, the description carries the full burden. It adds valuable behavioral context by detailing decision semantics ('accept (once), acceptForSession (don't ask again this session), decline, cancel'), which goes beyond basic approval. It doesn't cover potential irreversible effects or auth requirements, but the core behavior is transparent.
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 concise and well-structured: it leads with the main action, then explains how to get the requestId, and finally lists the decisions. Every sentence is informative with no unnecessary clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with no output schema, the description adequately covers how to use it: requestId source, decision options, and request types. It doesn't explain the return value, but that is not critical for this straightforward approval action.
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 schema covers only requestId (33% coverage). The description compensates by explaining the decision enum values and mentioning the thread context for threadId. The requestId schema description is reinforced, and the added decision semantics significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Approve or decline a pending permission request' and specifies the resource types (command execution, file read, file change). It distinguishes itself from sibling tools like respond_to_user_input by focusing specifically on permission requests.
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 provides explicit guidance for obtaining the requestId ('Get the requestId from pending_actions or get_thread') and explains the meaning of each decision option. However, it doesn't explicitly state when not to use this tool or mention alternatives beyond the source tools.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently describes what the tool returns (a list of projects with counts) and implies read-only behavior with no side effects. It doesn't mention pagination or filtering, but for a simple list tool this is acceptable.
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 that is front-loaded with the action verb 'List' and immediately states the resource. It includes only useful clarifications like '(workspaces/repos)' and the specific output metrics, 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?
For a simple list tool with no output schema, the description fully conveys what the user should expect: a list of projects with thread counts. It covers the tool's scope and output adequately, and there are no missing parameters or complex behaviors to describe.
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 zero parameters and the schema is empty (100% coverage), so the baseline for 0-param tools is 4. The description doesn't need to explain parameter semantics as there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb 'List' and resource 'projects (workspaces/repos)' scoped to 'T3 Code'. It also mentions the unique output (per-project counts of active and attention-needing threads), which distinguishes it from sibling tools like list_threads or t3_status.
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?
While it does not explicitly state when to use it or mention alternatives, the description provides clear context by describing the tool's output. It implies usage for obtaining an overview of projects and their thread activity, and no exclusions are given. This matches the 'clear context, no exclusions' level.
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?
With no annotations provided, the description takes on the full burden of disclosing behavior. It reveals that the tool starts an agent turn, reuses existing settings unless overridden, queues messages if the agent is busy, and returns immediately. It could also mention potential errors or authentication requirements, but the core behavioral traits are well covered.
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, all information-dense with no fluff. The most important facts (send, start turn, return behavior) are front-loaded, and the later sentences provide necessary behavioral details without repetition.
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?
Since there is no output schema, the description appropriately explains the return behavior: 'Returns immediately; use wait_for_turn or get_thread to see the reply.' It also covers the queuing behavior and parameter inheritance, making it complete for an AI agent to use correctly without requiring external context.
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 75%, so some params (message, threadId, runtimeMode) are already described. The description adds value by explaining that runtimeMode and interactionMode are overrides of the thread's current settings ('unless overridden'), which is not obvious from the bare enum names. It also clarifies that the thread must be existing, reinforcing threadId semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send a user message to an existing thread and start an agent turn.' This distinguishes it from create_thread (new thread), wait_for_turn, and get_thread (retrieving replies). It uses a specific verb and resource, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions when to use the tool (to send a message to an existing thread) and provides alternative tools: 'use wait_for_turn or get_thread to see the reply.' It also explains the queuing behavior when the agent is mid-turn, giving clear context without needing to list every sibling.
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?
With no annotations, the description fully discloses key behavioral traits: blocking until turn finishes or approval/input is requested, returning the latest assistant message or pending request, and timeout behavior (default 120s, max 300s) returning current state. This goes beyond what the schema provides and gives the agent a clear mental model of the tool's side-effect-free, wait-for-request nature.
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 with no fluff. The first sentence states the core blocking and return behavior, the second gives usage context, and the third covers timeout. Every sentence earns its place, and the format is front-loaded with the primary action.
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?
Without an output schema, the description must describe return values, which it does ('latest assistant message or the pending request'). It also covers when to use the tool and timeout behavior. For a simple 2-parameter wait tool with no annotations, this is complete and leaves no critical gaps.
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 must compensate. It adds meaning for both parameters: threadId is implied via 'the thread's current turn' and timeoutSeconds is explained with default and max values. It does not mention the minimum of 5s (schema provides that) or explicitly state optionality, but the default implies it. Overall, the description enriches parameter understanding.
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 ('Block') and clearly identifies the resource (thread's current turn). It distinguishes itself from siblings by specifying it returns after the turn finishes or when approval/input is requested, and it is explicitly positioned after send_message/create_thread. This is a specific and unambiguous purpose.
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 explicitly states 'Use after send_message or create_thread for a single round-trip', providing clear usage context and differentiating it from other waiting tools. It does not explicitly name alternatives or exclusions, but the context is clear enough for correct selection.
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

Copy to your README.md:

[![t3code-mcp MCP server](https://glama.ai/mcp/servers/ThomasCrund/t3code-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ThomasCrund/t3code-mcp)

Score Badge

Copy to your README.md:

[![t3code-mcp MCP server](https://glama.ai/mcp/servers/ThomasCrund/t3code-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ThomasCrund/t3code-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ThomasCrund/t3code-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server