TaskMarket MCP Server

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct action and role. Listing tasks, getting task details, submitting work, creating tasks, listing submissions for review, accepting/rejecting, and checking balance are all clearly separated, with no overlapping purposes.
Naming Consistency5/5
All tools follow a consistent 'tm_' prefix with a verb_noun pattern (e.g., list_tasks, get_task, submit_work, create_task). Minor plural/singular differences in accept/reject are negligible.
Tool Count5/5
With 9 tools, the server covers both worker and requester workflows without bloat. Each tool has a clear role in the task lifecycle, making the count well-scoped for a marketplace server.
Completeness4/5
The core lifecycle is covered: create, read, submit, review, accept/reject. Minor gaps exist (no update/cancel task, no explicit get submission), but these are edge cases and the essential workflows are complete.
Average 3.7/5 across 9 of 9 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that the tool never auto-accepts, which is a meaningful trait, but it omits whether the operation is read-only, what the response looks like, ownership requirements, or any side effects. Minimal disclosure for a list operation that may be expected to be safe.
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?
Two sentences, front-loaded with purpose, no filler. The key behavioral note ('never auto-accepts') is included efficiently. Slightly under-specified in content but concise in form.
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 there is no output schema and no annotations, the description should compensate by explaining what kind of data is returned and how it connects to accepting/rejecting. It only states the purpose and a behavioral caveat. For a 1-param tool, it's better than many but still leaves the agent guessing about the return structure and workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 taskId parameter. It does not mention taskId at all, nor does it specify that the taskId refers to the posted task's identifier. No information beyond the schema's bare property type is 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 states a specific verb ('List'), a clear resource ('submissions for a task you posted'), and adds the review context. It distinguishes itself from 'tm_my_submissions' by specifying 'you posted' (requester view), and from accept/reject tools by noting it only presents work.
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?
It implies usage when the user is a requester wanting to see submissions for review. The phrase 'never auto-accepts' hints that acceptance is separate, but it does not explicitly name alternatives like 'tm_accept_submissions' or 'tm_reject_submission'. Clear context but no explicit when-not-to-use or sibling routing.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get full details,' which implies a read operation, but it does not describe possible errors (e.g., task not found), return structure, or any prerequisites. For a simple getter this is thin; it adds no safety or failure mode context beyond the intuitive read-only 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?
The description is a single, front-loaded sentence that says exactly what the tool does without any fluff. It is appropriately sized for such a simple tool and earns its place.
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 no annotations, no output schema, and 0% parameter coverage, the description is not complete enough for reliable invocation. It does not explain what 'full details' include, how to obtain taskId, or any error handling. The low complexity keeps it from being a 1, but there are clear 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 input schema has a single required string parameter 'taskId' with 0% schema description coverage. The description does not mention taskId at all, nor does it explain where the ID comes from (e.g., tm_list_tasks). The parameter name gives some implicit meaning, but the description fails to compensate for the lack of schema documentation.
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 'Get' and the resource 'full details of one TaskMarket task.' It explicitly scopes to a single task, which distinguishes it from siblings like tm_list_tasks and tm_submit_work. The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention 'use this when you need details for a specific task' or exclude cases like listing all tasks. The agent must infer from the name and siblings.
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 provided, the description carries the full burden of disclosing behavioral side effects. It does disclose the relay fee (0.001 USDC) and the confirm requirement, which is valuable. However, it omits whether the action is irreversible, what permissions are needed, or what the response/impact is. This is partial disclosure but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and the key constraints (fee and confirm flag). No filler or redundancy; it earns its place.
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 mutation tool with no annotations, no output schema, and where two of three parameters lack descriptions, the description is insufficient. It does not explain what happens after rejection (e.g., task status change, notification), any side effects, or how to obtain the required IDs. An agent would need to guess at several critical aspects.
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 only 33% (only 'confirm' has a description). The description repeats the confirm requirement but adds no new meaning for 'taskId' or 'submissionId' — those remain undefined. Since coverage is low, the description should compensate, but it does not clarify what these identifiers refer to or how they interact.
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 ('Reject') and the specific target ('spam or low-quality submission'), which immediately distinguishes it from the sibling 'tm_accept_submissions'. The additional mention of the relay fee and the confirm requirement add context without muddling the purpose.
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 provided on when to use this tool versus its alternatives (e.g., 'tm_accept_submissions' or 'tm_task_submissions'). The description mentions a prerequisite (confirm:true) but does not explain the decision context for rejection or contrast with other actions. An agent would have to infer usage from the tool name and sibling list.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions environment requirements but omits details about what happens after submission—whether it is idempotent, returns a submission ID, if resubmission is allowed, or any side effects. This is similar to the update_drive calibration example, which scored 2 for lacking such information.
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 redundancy. It efficiently conveys the purpose and a critical prerequisite in just 12 words, using clear language without unnecessary elaboration.
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 absence of annotations and output schema, the description is too minimal. It does not mention return values, error conditions, side effects, or any post-submission behavior. For a mutation tool with only two parameters, this leaves significant gaps in what an agent needs to know to use it 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 schema description coverage is 0%, so the description must compensate. It provides a basic mapping: 'a file' corresponds to the file parameter and 'TaskMarket task' corresponds to taskId. This gives enough semantic understanding to infer the parameters' roles, though it lacks detail on formats, constraints, or expected values.
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 and resource: 'Submit work (a file) for a TaskMarket task.' It distinguishes from sibling tools like tm_list_tasks, tm_get_task, tm_my_submissions, and tm_wallet_balance, which are all read-only or list operations. This is the only tool that performs a write/submission action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates a prerequisite ('Requires TASKMARKET_API_URL and worker wallet'), but does not explicitly state when to use this tool versus alternatives or when not to use it. It implies usage is for delivering a completed file for a task but lacks explicit exclusions or comparative guidance.
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 present, so the description must carry the full burden of disclosing behavior. It states a list action, which implies a read-only operation, but does not disclose nuances like pagination, sorting, filtering, or what 'available' means. The description is too terse to provide adequate transparency for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the action and resource. It includes a clarifying parenthetical without unnecessary fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with full parameter coverage, the description gives a basic but not fully complete picture. It does not mention return format, pagination, or how to access task details via sibling tools. Without annotations, this leaves some ambiguity about behavior but remains adequate for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'limit' with a clear description 'max tasks'. The tool description adds no additional parameter context, but the schema already provides sufficient meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource 'TaskMarket tasks' and clarifies the task types in parentheses. This clearly distinguishes it from siblings like tm_get_task (fetch single task) and tm_my_submissions (list own submissions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for browsing available tasks but does not explicitly contrast with siblings or state when to use this tool vs. alternatives. There are no exclusion criteria or alternative tool references, so the guidance is only implicit.
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 states the operation is 'List' (implying read-only) but does not disclose auth requirements, return format, pagination, or what constitutes a 'submission'. This is minimal behavioral disclosure for a tool with no annotation support.
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, front-loaded sentence with no waste. It conveys the core action and scope in 8 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?
Given the low complexity (zero params, no output schema), the description is minimally viable but lacks details about the returned data structure or what 'submissions' includes. Sibling tools provide context, but the description could still mention ordering or fields.
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 schema coverage is 100%. The description adds context by noting the operation is scoped to 'this wallet', clarifying that the wallet is determined contextually. This is adequate for a no-parameter tool.
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 ('List') and resource ('all submissions made by this wallet'), clearly distinguishing it from sibling tools like tm_list_tasks and tm_submit_work. The 'made by this wallet' scope adds precision.
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 (to view submissions for the current wallet) but does not explicitly mention when to use it over alternatives or any prerequisites. No exclusions or alternative references are 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?
With no annotations, the description carries the full burden. It discloses a 0.001 USDC relay fee and the confirm:true requirement, which adds transparency about cost and authorization. However, it does not describe side effects on task state or reversibility, leaving gaps for a mutation 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 sentences that are entirely purposeful: the first states the operation and key constraint, the second lists requirements and cost. No fluff, front-loaded with the core action.
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?
Covers all critical call information: operation, share basis points, requirement for confirm:true, and fee. No output schema exists so return values are not needed. Could elaborate on error conditions or idempotency, but it is sufficiently complete for a straightforward accept 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?
Schema coverage is 67%, and the description adds meaning beyond the schema by explaining that share basis points sum to 10000 and that winners are in rank order (implied by 'explicit winner specs'). It also emphasizes confirm:true as a mandatory authorization, which enriches the schema's boolean 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?
States a specific verb ('Accept') and resource ('winners on a bounty/benchmark task') with explicit detail about share basis points summing to 10000. Clearly distinguishes from sibling tools like tm_reject_submission and tm_submit_work by naming the exact operation and its format.
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?
Provides clear context for when to use (accepting winners) and states prerequisites (confirm:true, explicit winner specs), but does not explicitly exclude alternative tools or describe when not to use. The requirements guide usage without naming 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?
No annotations are provided, so the description carries the burden. 'Show' implies a read-only operation, but it does not state return format, whether it requires authentication, or any other behavioral details. For a simple balance query this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that fully conveys the tool's purpose with zero wasted words.
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 the tool has no parameters, no output schema, and a simple unambiguous purpose, the description is complete enough for an agent to select and invoke it 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 zero parameters, so the description does not need to explain parameter details. Baseline for 0 params is 4; no additional param info is necessary.
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 'Show' and a clear resource 'worker USDC balance'. It distinguishes from sibling tools which are all task-related, making the 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 makes it clear when to use this tool: whenever you need the worker's USDC balance. There are no sibling tools for balance, so no exclusions are necessary, but explicit guidance is minimal.
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 provided, the description carries the full burden. It discloses the cost implication, escrow, the confirmation gate, and specific rejection conditions (balance, network, confirm value), plus a retry policy. This is exceptionally transparent for a mutation tool with financial impact.
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?
Every sentence is purposeful. The description front-loads the purpose and cost, then delivers safety-critical behavior in compact, structured sentences. It's dense but not bloated, with no 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 tool that spends money and has strict safety requirements, the description covers all the essential decision points: what it does, what's required, when it refuses, and a policy on retries. The lack of an output schema is minor here because the primary risk is pre-call (cost/confirmation), which is fully addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the confirm parameter's role and the maxSpend relationship, but doesn't add new parameter-level details beyond what the schema already provides. It meets the baseline without surpassing it.
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 verb and resource ('Create a TaskMarket task') and adds critical context (costs reward in USDC, escrowed on Base) that immediately distinguishes it from sibling read/list operations. An agent can tell exactly what this tool does.
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 clearly states the safety requirement (confirm:true after reviewing) and lists the refusal conditions (insufficient balance, wrong network, confirm not true). It doesn't explicitly name alternatives, but the context is clear that this is for task creation, and the 'Never retries a payment with unknown settlement' caveat adds important usage caution. Slight deduction for not explicitly contrasting with siblings.
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:

[![taskmarket-mcp MCP server](https://glama.ai/mcp/servers/Autonomy-Labs-Tech/taskmarket-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Autonomy-Labs-Tech/taskmarket-mcp)

Score Badge

Copy to your README.md:

[![taskmarket-mcp MCP server](https://glama.ai/mcp/servers/Autonomy-Labs-Tech/taskmarket-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Autonomy-Labs-Tech/taskmarket-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/Autonomy-Labs-Tech/taskmarket-mcp'

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