Google Tasks MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, but complete_task and reopen_task are shortcuts for update_task, creating some overlap. The descriptions clarify the difference, so an agent can usually choose correctly.
Naming Consistency5/5
All tool names follow a consistent imperative verb_noun pattern in snake_case, such as list_tasks, create_task, and delete_task. Even compound actions like clear_completed_tasks fit the same predictable style.
Tool Count5/5
Nine tools is a well-scoped size for a Google Tasks server, covering task list listing and full task lifecycle operations. Each tool has a clear role without redundant bulk.
Completeness3/5
Task CRUD and status transitions are well covered, but task list management is incomplete: there is no create_task_list, update_task_list, or delete_task_list. This leaves a notable gap for agents needing to manage multiple lists beyond reading them.
Average 3.1/5 across 8 of 9 tools scored.
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 is passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'Get,' which implies read-only, but does not specify behavior on missing IDs, error cases, or whether the full task object is returned. This is a minimal disclosure.
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?
One short sentence with no fluff, front-loading the core action. It is efficient, though it sacrifices the parameter clarity that would make it more useful. No structural issues.
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 simple get operation with a small schema and no output schema, the description is too thin. It omits the critical distinction between tasklist_id and task_id, and also fails to mention any return or error semantics. An agent has just enough to guess, but not enough to invoke reliably.
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 compensate, but it says 'by ID' singular while two required parameters exist (tasklist_id and task_id). It does not explain which parameter is which or why both are needed, which is misleading for an agent trying to populate the arguments.
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?
States a clear verb and resource ('Get a single task by ID'), and the word 'single' loosely differentiates it from list_tasks. However, it does not explicitly contrast with list_tasks or other task operations, and ambiguity remains because two IDs are required.
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 on when to use this tool versus siblings such as list_tasks or update_task. The context is implied by 'by ID,' but there are no explicit alternatives, prerequisites, or when-not 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?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read/list operation but does not explain default filtering, pagination limits, hidden-task behavior, or what the response contains. The unsupported 'search query' mention also risks misleading an agent into passing a nonexistent parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose, which is good. But the final clause about a search query is inaccurate and not supported by the schema, so the single sentence does not fully earn 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?
The tool has five parameters, no annotations, and no output schema, so the description is the primary guidance. It omits useful invocation context such as defaults, response shape, or how to obtain a valid tasklist_id, and it references a filter that is not in the schema. The description is not sufficient for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the description adds a 'search query' filter that does not exist in the input schema, which is actively misleading rather than additive. It contributes no useful parameter 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'List tasks in a task list.' It is distinguishable from siblings like get_task and list_task_lists. However, mentioning 'search query' when no query parameter exists in the schema introduces ambiguity and mildly undermines clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool versus alternatives such as get_task or list_task_lists. 'Optionally filter by status or search query' implies a filtering use case, but there are no exclusions, prerequisites, or sibling comparisons, and the query mention is not backed by the schema.
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 behavioral burden. 'Permanently delete' clearly conveys that the action is destructive and irreversible, which is valuable. However, it does not disclose possible side effects, permission requirements, or whether deletion cascades to related resources.
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 clear, front-loaded sentence with no wasted words. It is concise and scannable, though it sacrifices useful detail for brevity.
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 destructive two-parameter tool with no annotations and no output schema, the description is incomplete. It provides the core intent and permanence, but lacks usage context and parameter clarification, so an agent does not have enough information to confidently invoke it correctly.
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?
The schema has 0% description coverage and the description provides no explanation of task_id or tasklist_id. The description omits any meaning around the two required identifiers, leaving the agent to guess which ID refers to the task and which refers to the containing task list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'a task,' plus the modifier 'permanently,' making the core purpose unambiguous. It does not explicitly distinguish itself from sibling tools like clear_completed_tasks, but the singular 'a task' signals targeted deletion of one task.
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 about when to use this tool versus alternatives such as clear_completed_tasks, update_task, or complete_task. The description does not mention whether tasks must be completed before deletion, what happens to subtasks, or any exclusions.
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 must carry the full burden of behavioral disclosure. 'Clear' suggests destructive bulk behavior, but the description does not state whether tasks are permanently deleted, what happens to subtasks or list metadata, or how the operation behaves when no completed tasks exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the action and scope with no filler, repetition, or unnecessary detail. It is efficiently structured for an agent to parse.
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?
With no annotations, no output schema, and no parameter descriptions, the description alone must fully equip an agent to invoke a bulk destructive operation. It leaves ambiguity about whether 'clear' means permanent deletion and does not differentiate this operation from delete_task, creating a meaningful correctness gap.
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 provides no description for tasklist_id, so the phrase 'from a task list' is the only semantic clue that this parameter identifies the list whose completed tasks are cleared. This is useful but minimal; it does not explain requiredness, format, or scope beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Clear'), a specific resource ('all completed tasks'), and a scope ('task list'), which makes the core operation clear. It does not explicitly contrast with sibling delete_task, but the plural 'completed tasks' distinguishes it from single-task operations.
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?
There is no guidance on when to use this tool instead of delete_task, complete_task, or reopen_task, and no mention of prerequisites or cautions for a bulk operation. The intended use is only implied by the action phrase rather than explicitly stated.
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 must carry the behavioral burden, and it only states the state transition. It says nothing about idempotency, behavior when the task is not completed, permission requirements, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with a helpful parenthetical clarification ('un-complete') and no filler. Every word contributes.
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 no parameter documentation, this is thin. It captures the basic action but lacks the behavioral and invocational context needed to call it with confidence in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to task_id or tasklist_id beyond their self-explanatory names. The two parameters' relationship (which list owns the task) is left for the agent to infer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Reopen (un-complete)') and names the resource ('completed task'), making the core operation clear. It doesn't explicitly contrast with sibling complete_task, but the parenthetical and completed-task qualifier distinguish the reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a completed task' implies the tool is for tasks that have already been completed, which is a precondition for use. However, it gives no explicit when-not-to-use guidance or alternatives such as complete_task or update_task.
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 provided, the description carries the full behavioral burden, but it only says 'Create a new task' and does not disclose side effects, permission needs, ID handling, or what happens on success or failure. It is not misleading, but it is thinner than the mutation essentials.
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 filler. It names the action and object compactly, which is appropriate for the simple create-tool shape.
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 five-parameter mutation with no annotations and no output schema, the definition is incomplete: the agent is not told what the tool returns, what defaults apply beyond the schema, or when to reach for this vs a sibling. The schema covers parameters but not the surrounding 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?
Schema description coverage is 100%, so the schema already documents all five parameters, including the '@default' tasklist_id convention and RFC 3339 due format. The description adds almost no parameter-level meaning, which keeps it at the schema-covered baseline.
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: it creates a new task inside a task list, so it is immediately distinguishable from the sibling operations (update, complete, reopen, delete). No ambiguity remains about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool instead of update_task, complete_task, or list_tasks, and it states no prerequisites such as needing a task list ID. An agent must infer usage from the tool name and parameters.
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 'Mark a task as completed' and calls it a shortcut, without explaining whether the operation is reversible, idempotent, what other fields are affected, whether permissions are required, or what response is returned. This is a notable gap for a mutation 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 front-loaded sentence with no filler. The parenthetical 'shortcut for update_task' adds useful relational context without bloating the description.
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 two-parameter mutation tool with no annotations, no output schema, and no parameter descriptions, the description is too thin. An agent can infer the core action but is left without guidance on expected inputs, behavioral details, or likely return behavior, making the definition incomplete in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description does not explain tasklist_id or task_id. The parameter names are somewhat self-explanatory, but the description adds no meaning beyond the raw schema and fails to clarify required relationships or formats.
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 the precise action ('Mark a task as completed') and clearly identifies the resource. It also distinguishes itself from the general update_task by calling it a shortcut, making the specialized purpose immediately obvious to an agent.
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 parenthetical 'shortcut for update_task' implies this tool is the specialized completion variant, but it does not explicitly state when to prefer it over update_task or when to avoid it. Sibling tools like reopen_task are not addressed, leaving usage context mostly implied.
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 transparency burden. It adds a meaningful behavioral trait—unspecified fields are left unchanged—but it does not disclose error behavior, permissions, idempotency, or what the update returns.
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 front-loaded sentence with no filler. It is concise and easy to parse, though its brevity leaves useful behavioral and routing details unstated.
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 mutating tool with no annotations and no output schema, the description is thin: it does not mention return values, error conditions, or how to choose between update_task and the status-specific sibling tools. The partial-update guidance is helpful, but an agent is left guessing about side effects and success signals.
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 only 33%, but the description compensates partially by explaining that supplied fields are update targets and omitted fields remain untouched. It still leaves title, notes, task_id, and tasklist_id without individual descriptions, though their names are largely self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Update') and resource ('an existing task'), and it is distinguishable from create_task via the word 'existing'. However, it does not explicitly distinguish update_task from complete_task or reopen_task, which also perform task updates.
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?
'Only supply the fields you want to change' gives useful context for partial updates, implying the tool is for modifying existing tasks. It does not name alternatives such as complete_task or reopen_task for status-specific changes, nor state when not 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. 'List' clearly signals a non-destructive read, and 'for the authenticated user' identifies the auth scope. It does not mention return format or pagination, but those are secondary for a simple read 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?
One efficient sentence, front-loaded with the verb and resource, with no redundant or filler wording.
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 zero-parameter, read-only listing operation, the description is nearly complete. It would be slightly stronger if it explicitly stated the return value shape, but with no output schema the meaning is still clear from 'List all ...'.
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 there is nothing for the description to explain beyond the baseline. The description correctly implies that no inputs are 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 uses a specific verb ('List'), a specific resource ('Google Task lists'), and a clear scope ('all ... for the authenticated user'). This makes it easy to distinguish from sibling list_tasks, which targets individual tasks.
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?
There is no explicit comparison to sibling tools or statement of when not to use it, so the agent must infer usage from the resource name. The scope 'all ... for the authenticated user' provides some contextual guidance, but no alternative routing.
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

claude-mcp-gabrielandarina-google-task MCP server

Copy to your README.md:

[![claude-mcp-gabrielandarina-google-task MCP server](https://glama.ai/mcp/servers/gabriel-serra-aus/claude-mcp-gabrielandarina-google-task/badges/card.svg)](https://glama.ai/mcp/servers/gabriel-serra-aus/claude-mcp-gabrielandarina-google-task)

Score Badge

Copy to your README.md:

[![claude-mcp-gabrielandarina-google-task MCP server](https://glama.ai/mcp/servers/gabriel-serra-aus/claude-mcp-gabrielandarina-google-task/badges/score.svg)](https://glama.ai/mcp/servers/gabriel-serra-aus/claude-mcp-gabrielandarina-google-task)

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/gabriel-serra-aus/claude-mcp-gabrielandarina-google-task'

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