notebooklm-mcp

by gracelee087

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools target distinct resources and actions: notebook lifecycle, source management, research, and studio are clearly separated. Potential confusion exists between research_start and research_and_ask (both initiate research) and between studio_create and studio_revise (both generate artifacts), but descriptions clarify the workflow differences.
Naming Consistency3/5
Resource-based tools follow a consistent <resource>_<action> pattern (notebook_*, source_*, studio_*), but several tools deviate: download_artifact, refresh_auth, batch, pipeline, tag, and research_and_ask break the convention. The naming is readable and accessible, though mixed styles reduce overall predictability.
Tool Count4/5
At 19 tools, the set is on the heavier side but justified by NotebookLM's broad feature surface: notebooks, sources, research, studio, sharing, and meta-orchestration all receive coverage. The number is not excessive and each tool serves a distinct purpose.
Completeness4/5
Core lifecycle operations are covered for notebooks (create, list, delete, query) and sources (add, sync, get_content), and research/studio workflows are complete. Notable gaps include lack of notebook update/rename, source deletion, and source listing, but these are minor and workaroundable.
Average 3.9/5 across 19 of 19 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 22, 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?
The description discloses that the tool returns the share URL when enabled, which is helpful. However, it does not specify what happens when disabled, whether permissions are needed, or the effect on existing links. Since there are no annotations, the description carries the full burden but provides minimal behavioral detail.
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 extremely concise at two sentences, with no filler. It front-loads the main action and includes the key return behavior in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (2 parameters, boolean toggle), and the description covers the primary function and return value. However, it omits important context about the disabled state, prerequisites, and relationship to other sharing tools, making it only minimally 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 explain the parameters. It fails to mention notebook_id or the enable boolean explicitly, though 'when enabled' loosely implies the 'enable' flag. The effective behavior of toggling is not clarified for either parameter value.
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 'Toggle' and the resource 'public share link on a notebook', specifying the action and object. It distinguishes from sibling tools like notebook_share_invite by focusing on the public link mechanism, and notes the return value (share URL when enabled).
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. The description does not mention prerequisites, conditions for enabling/disabling, or how this relates to notebook_share_invite. Usage context is only implied by the verb 'toggle', but no explicit direction is given.
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 must bear all responsibility for behavioral disclosure. It only says 'Return' with no mention of potential errors (e.g., missing source, permissions) or any side effects. While it implies a read operation, it does not explicitly state that it is non-destructive or requires existing data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the action and object, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters, output schema exists), so the description is arguably sufficient for the core purpose. However, it lacks any usage context, such as when to use this against notebook_query or source_add, and does not mention any behavioral prerequisites (e.g., source already processed). This makes it minimally viable but not 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. It does not explain 'source_id' or 'notebook_id' beyond their names, nor how they relate. For a tool with two self-explanatory parameters, this is acceptable but still lacks semantic context (e.g., that source_id is scoped by notebook_id).
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 returns extracted text/metadata of a single source, using a specific verb ('Return') and resource ('source'). This distinguishes it from sibling tools like source_add (which adds sources) and source_sync_drive (which syncs drive content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., source must be added first) or compare it to sibling tools like source_add or source_sync_drive. This is a clear gap for an agent deciding between related source tools.
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 for behavioral disclosure. It only states what the tool does, not how: no mention of result aggregation, error handling, concurrency, permissions, or side effects. This gap could mislead an agent about the tool's execution model.
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 front-loads the core purpose with a concrete example. Every word is useful and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too sparse for a generic dispatch tool. It lacks essential context about how operations are executed (e.g., sequentially or in parallel), how parameters map to the operation, and how errors or partial failures are reported. An agent would need additional documentation to use this safely and effectively.
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 all three parameters (notebook_ids, operation, params), and the description only provides a single example value for operation. It does not explain the structure or purpose of the 'params' object or how notebook_ids should be formatted, leaving the agent to guess.
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 a specific verb+resource+scope: 'Run a single tool operation across many notebooks.' The example operation='notebook_query' reinforces the intended use and distinguishes it from single-notebook tools and other wrappers like pipeline.
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 'across many notebooks' implies the use case for batch operations, but there is no explicit guidance on when to choose this over alternatives like cross_notebook_query or when not to use it (e.g., for a single notebook). No direct comparison to sibling tools is provided.
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 full responsibility for disclosing behavior. It only mentions 'refresh' and the source_id parameter effect, but does not reveal what 'refresh' entails—whether it overwrites data, requires permissions, or has side effects. This is insufficient for a mutation-type 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, front-loaded with the action and resource, and contains no filler. Every word is functional, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too terse for a tool that performs a mutation. It does not explain what 'refresh' means, what prerequisites exist (e.g., authentication or existing Drive link), or what the output represents. The required notebook_id parameter is not documented, leaving the tool incomplete for straightforward use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning for source_id ('If source_id is None, refresh all'), but it fails to explain notebook_id, a required parameter. With two parameters, half are undocumented, leaving a significant gap in 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 purpose: 'Refresh Drive-linked sources.' It specifies the action (refresh), the resource (Drive-linked sources), and includes a scope condition ('If source_id is None, refresh all') which adds specificity and distinguishes it from sibling tools like source_add or source_get_content.
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 want to refresh Drive-linked sources) and even clarifies behavior for a specific parameter, but it does not provide explicit alternatives or when-not-to-use guidance. Sibling tools like source_get_content or source_add are not referenced, so the usage context is only implied.
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 fully disclose behavioral traits. It reveals the three modes but does not explain the effect of 'set' (e.g., does it replace all existing tags?), consequences of removal, reversibility, or permission requirements. For a mutation-capable tool, this 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?
The description is a single sentence that front-loads the main action and target. Every phrase is informative, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema lowers the need to describe return values, and the parameters are simple. However, the lack of annotations and the ambiguous 'set' mode leave the description incomplete for a mutation tool, especially regarding side effects and failure behavior. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate; it adds the allowed mode values and clarifies that tags are applied to one or more notebooks. However, it leaves 'set' semantics and potential constraints on tag values or duplicate handling unaddressed, so it only partially compensates.
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 ('Add/remove') and names the resource ('tags on one or more notebooks'), clearly distinguishing this tool from siblings that handle notebooks, sources, or research. The mention of modes ('add','remove','set') further clarifies its scope.
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 managing tags on notebooks, but it gives no explicit when-to-use guidance or mentions alternatives. It is self-evident enough for a tagging operation, yet lacks exclusions or context about when it should be preferred over related notebook tools.
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. It only states the action without mentioning side effects (e.g., sends an email), permission requirements, idempotency, or whether collaborators are immediately granted access. This is a significant 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?
A single sentence that is front-loaded and contains no filler. Every word contributes to the core purpose, making it easy to parse at a glance.
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 low complexity (2 simple params) and the existence of an output schema, the description is largely complete for selection and invocation. It lacks broader context about preconditions or comparison with similar sharing tools, but for a simple invite operation, it satisfies most informational needs.
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 0%, so the description must compensate. The sentence 'Invite collaborators by email to a notebook' implicitly ties 'emails' to the recipients and 'notebook_id' to the target notebook, adding some meaning beyond the raw schema. However, it does not elaborate on formats, validation, or behavior for invalid inputs.
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 a specific action ('Invite') and resource ('collaborators by email to a notebook'). It distinguishes from the sibling 'notebook_share_public' by the 'by email' qualifier, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (use when you want to invite collaborators via email), but it does not explicitly contrast with alternatives like notebook_share_public or mention any prerequisites or exclusions. The context is clear but lacks explicit guidance on when to choose this tool over others.
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 full responsibility. It discloses the sequential execution and the $prev mechanism, which is valuable behavioral context. However, it does not mention error handling, potential side effects of invoking other tools, or whether the pipeline can be aborted. This is moderate transparency but leaves important 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 extremely concise, consisting of two sentences. It front-loads the core purpose and adds a necessary detail about $prev without any wasted words. Every sentence 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?
Given the tool's complexity (a meta-tool that runs other tools), the description explains the essential mechanics but omits important context such as error handling, behavior on step failure, and what the final output actually is (though an output schema exists). It is adequate for basic understanding but incomplete for robust usage.
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 provides no description for the 'steps' parameter (0% coverage). The description compensates by explaining the expected structure of each step as '{ tool, params }' and by describing the $prev data flow. This adds significant meaning beyond the bare schema, though it could be even more explicit about the 'params' object.
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's function: 'Run a sequence of tool invocations.' It specifies the verb (run), the resource (a sequence of tool invocations), and the structure of each step. It distinguishes from siblings like 'batch' by focusing on sequential execution and data passing, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied rather than explicitly stated. The description implies this tool should be used when you need to chain tool invocations and pass output between steps ($prev). However, it does not provide explicit when-to-use/when-not-to-use guidance or mention alternatives such as 'batch' or direct calls.
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 burden of behavioral disclosure. It states the return shape but does not clarify whether the operation is read-only, whether it refreshes tokens, or what happens on failure. The word 're-validate' hints at a check but lacks side-effect transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence plus a return type specification. It is efficient and front-loaded with the action and purpose, with no wasted words.
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 simple nature of this auth-checking tool, the description covers the essential purpose and return value. The presence of an output schema (for the return shape) reduces the need to explain return details. It lacks error handling or failure-mode info but remains adequate for the tool's simplicity.
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 no conflicting or extra parameter info, and since there are no parameters, no further 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 clearly states the tool re-validates the stored Google session, using a specific verb and resource. It is distinct from the sibling tools, which focus on notebooks, sources, research, etc., so no confusion arises.
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 does not specify when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It implies a session check but lacks explicit context for an agent to decide when to invoke it.
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 disclose behavioral traits on its own. It does reveal a side effect (the exchange is persisted in NotebookLM's chat history) and previews the return shape, which is useful. However, it does not address whether the operation is read-only, if it requires special authentication, or if there are rate limits or costs, leaving a partial transparency 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 short sentences, front-loaded with the primary purpose, followed by the key side effect and return fields. No fluff, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the description covers the core operation, side effect, and return shape. It is concise and complete enough for straightforward use, though it lacks explicit guidance on when to use it or how it differs from related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining the parameters. The phrase 'inside a notebook' hints at notebook_id and 'Ask a question' hints at question, but it does not clarify formats, constraints, or relationships. It adds minimal meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Ask a question') and resource ('inside a notebook'), and specifies the outcome ('return the grounded answer'). It distinguishes itself from siblings like cross_notebook_query and research_and_ask by focusing on a single notebook and a chat-persisted exchange.
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: you use this tool when you need to ask a question within a specific notebook. However, it does not explicitly say when to prefer this over alternatives like cross_notebook_query or research_and_ask, nor does it mention any exclusions or prerequisites.
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 full burden for behavioral disclosure. It indicates a mutation ('revise') but does not state side effects, reversibility, permissions, or what 'revisable artifact' entails. This is a significant 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 wasted words. It delivers the core purpose immediately, though the parenthetical is slightly vague. Overall, it is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and clarifies the instructions parameter, but lacks parameter details and behavioral context. With an output schema present and only 3 required params, it is borderline adequate. The absence of annotations and low schema coverage leaves gaps, so a 3 is appropriate.
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 description adds clarity to the 'instructions' parameter ('with new instructions') but does not explain notebook_id or artifact_id. Since schema coverage is 0%, the description should compensate more, but the parameter names are self-explanatory. Partial compensation leads to a mid-range score.
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 'Revise' with a clear resource: 'an existing slide deck (and any revisable artifact)'. This distinguishes it from sibling tools like studio_create, which creates new artifacts. The scope is clearly stated.
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 context: for revising an existing artifact, not for creating new ones. However, it does not explicitly mention alternatives or when not to use, so it lacks explicit exclusions. The context is clear enough, hence 4.
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 key behaviors: per-notebook failure handling (errors captured per notebook, no abort) and the overall return envelope. This goes beyond what the schema provides.
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 efficiently structured: a one-line purpose, a return type block, and an error-handling note. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, return structure, and error isolation, which is sufficient for a simple two-parameter tool. It could be more explicit about when to use this instead of notebook_query, but overall it's reasonably complete.
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 0%, so the description must add meaning. It clarifies that 'question' is shared across notebooks and that results are keyed by notebook_ids. However, it doesn't describe the expected format or constraints of the two parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (ask) and resource (notebooks) with scope ('across multiple notebooks'). It clearly implies a fan-out query, distinguishing it from the sibling notebook_query tool, though it doesn't explicitly name the alternative.
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 'Ask the same question across multiple notebooks' conveys the primary use case: querying multiple notebooks in one call. It doesn't state when-not-to-use or contrast with single-notebook querying, but the context is clear.
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?
Despite having no annotations, the description discloses key behaviors: it checks artifact status before downloading, only includes 'path' on success, and defaults to the latest artifact. It could detail what happens when the artifact is incomplete, but the output shape and conditional presence of path cover the main concerns.
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 compact and well-structured, with a clear purpose-first opening and concise follow-up sentences about default behavior and return format. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers the primary workflow and return shape. Minor gaps like incomplete status handling and dest_dir specifics remain, but the output schema and brevity reduce the overall completeness 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 has 0% description coverage, so the description must compensate. It adds important semantics for artifact_id (None means latest) and implies dest_dir's role via 'download to disk'. However, dest_dir itself is not explicitly explained, and notebook_id is left to the reader.
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's action: check status and download an artifact to disk. It also specifies the default behavior when artifact_id is None, making the tool's scope unambiguous and distinct from siblings.
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, including the option to omit artifact_id to fetch the most recent artifact. It doesn't mention alternatives or exclusions, but the use case is well implied.
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. It discloses that the tool always creates a fresh notebook (non‑idempotent) and explains the surprising behavior that the provided title is ignored until sources are added, resulting in an untitled notebook. It also mentions the return format, giving a clear expectation of 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core action and return value. The second paragraph adds necessary nuance about the RPC behavior and title handling. The RPC name ('CCqFvf') is slightly extra but not excessive; overall it is efficient 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 simple creation tool with one optional parameter, the description covers the essential aspects: what it does, what it returns, and the notable title quirk. Though it lacks explicit notes on prerequisites or errors, the tool is simple enough that the description is sufficiently complete 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?
Schema description coverage is 0%, so the description compensates by explaining the only parameter, title. It clearly states that title is accepted but not used directly—the notebook will auto‑title later. This adds meaning beyond the schema's plain type/default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Create a brand-new, empty notebook.' It also states the return shape ({ id, title, url }), which further clarifies the tool's purpose. This clearly distinguishes it from sibling tools like notebook_list, notebook_delete, and notebook_query.
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 usage context by contrasting this tool with the idempotent 'get recent draft' endpoint, indicating when to use this non‑idempotent creation method. However, it doesn't explicitly address when to choose this over the listed sibling tools, though the purpose itself makes that fairly obvious.
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 return fields, the meaning of 'ownership' values, and a specific known limitation (wXbhsf returns only the most-recent owned notebook). This is strong transparency, though it does not explicitly mention authentication requirements or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: three short paragraphs each serving a distinct purpose (purpose, output, limitation). There is no redundant information or fluff.
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 zero-parameter list tool with an output schema, the description covers purpose, output format, and a notable limitation. This is sufficient for an agent to select and invoke the tool correctly without additional 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?
The tool has zero parameters, so the schema already covers parameter semantics (trivially). Per the baseline rule for tools with no parameters, a score of 4 is appropriate; no additional descriptive compensation 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 clearly states the tool's function: 'List notebooks visible to the signed-in Google account.' It uses a specific verb ('List') and resource ('notebooks'), scoped to the signed-in account, which distinguishes it from sibling tools like notebook_create or notebook_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a simple listing use case but does not explicitly state when to use this tool over alternatives such as notebook_query. The known limitation about pagination hints at when it might not be suitable, but no alternative tool is referenced or exclusion is clearly stated.
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 the async behavior (returns immediately, 2-5 min generation), points to download_artifact for polling, and explicitly warns that non-audio artifact types raise NotImplementedError. This is transparent and sets correct expectations.
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, front-loaded with the main action. Each sentence adds value: action, async/return/poll, and limitation. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior (create, async, poll, limitation) and return format. It is missing parameter definitions and explicit alternative guidance (studio_revise), but for a tool with an output schema, the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions the default audio artifact type; it does not explain notebook_id, language, or instructions. The schema provides some semantics (enum, defaults) but the description adds almost no parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Start generating a Studio artifact (audio/podcast by default).' It clearly distinguishes this from sibling studio_revise (revision) and download_artifact (retrieval), and explicitly notes the default artifact type and unimplemented types.
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 explains the async workflow: returns immediately, poll download_artifact to check progress and retrieve. This gives clear usage context. However, it does not explicitly contrast with studio_revise or state when NOT to use this tool (beyond the NotImplementedError for non-audio types). It also doesn't mention prerequisites like needing an existing notebook id.
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 for behavioral disclosure. It explicitly states the permanent, irreversible nature, notes that NotebookLM has no trash/undo, and specifies the return value, adding meaningful context beyond the action itself.
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 concise sentences that front-load the action, provide the return value, and add a critical warning. Every sentence earns its place with no redundancy.
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 single-parameter delete tool, the description covers the essential behavioral context: the irreversible action, the confirmation requirement, and the expected return. The output schema presumably documents the response structure, and the absence of detailed error handling is acceptable for this complexity.
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 the only parameter, notebook_id, and the description does not explain its format, origin, or constraints. The parameter is self-descriptive, but the description fails to compensate for the lack of schema documentation, such as referencing notebook_list.
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 'Delete' and a clear resource 'a notebook', specifying 'permanently' to distinguish it from any soft-delete or other notebook operations. Sibling tools like notebook_create and notebook_list are clearly different operations.
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 that deletion is irreversible and requires caller confirmation, implying it should only be used after user consent. However, it doesn't explicitly name alternative tools or specify prerequisites like listing notebooks to obtain the ID, so it stops short of a full 5.
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 full responsibility for behavioral disclosure. It explicitly states that candidate sources are NOT automatically added, that the notebook must be empty, and it specifies the return shape. These are non-obvious, important behaviors that materially affect invocation and follow-up actions.
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 four sentences, front-loaded with the main purpose, then the return format, then crucial caveats. Every sentence carries meaningful information without repetition 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?
The description provides enough context to invoke the tool correctly: purpose, output format, prerequisite, and next-step action. It lacks a comparison to research_and_ask and does not describe error behavior or timeout handling, but for a non-destructive research starter with a simple output shape, it is largely complete.
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 0% description coverage, so the description must compensate. It clarifies that query is the topic and that notebook_id must refer to an empty notebook, but it never explains timeout_sec or its default behavior. This is partial compensation at best, leaving one parameter semantically undocumented.
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+resource: 'Kick off NotebookLM's Discover (Fast Research) flow on a topic.' It clearly states the tool starts a research discovery process and returns candidate sources, which distinguishes it from notebook querying or source management tools like research_and_ask or source_add.
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 usage context: it requires an empty notebook, advises creating one with notebook_create if needed, and directs the agent to use source_add to import selected sources. However, it does not explicitly compare this to research_and_ask or other research-related tools, so it stops short of full when-to-use vs. alternatives 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 full burden. It discloses server-side fetching for URLs, the ignored title for URLs, the default title for text, and the return object shape. It does not mention authentication, side effects, or error behavior, but covers the key behavioral nuances for the implemented kinds.
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, well-structured, and front-loaded with purpose and return. The bullet points break down kind-specific behavior efficiently, and every sentence adds value without redundancy.
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 presence of an output schema and four parameters, the description covers the essential context: return shape, kind-based behavior, and limitations. It does not explain notebook_id or potential errors, but the tool is simple enough that the description is sufficiently complete for an agent to use 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?
Since schema description coverage is 0%, the description compensates by explaining `value` semantics for text vs url, and the behavior of `title` for each. It doesn't explain `notebook_id`, but that is a common and obvious parameter. The warning that drive/file are not implemented also clarifies the `kind` enum 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 states a specific action ('Add a source to a notebook') and specifies the return shape. It clearly differentiates between supported kinds (text and url) and lists unimplemented ones, making its purpose unambiguous relative to siblings like source_get_content or source_sync_drive.
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 text vs url kinds, including how title is handled for each. It explicitly warns that drive and file are not implemented, which prevents misuse. However, it does not explicitly compare against alternative tools like source_get_content, though the name makes it fairly obvious.
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 behavioral burden and does so well: it discloses the ephemeral notebook lifecycle, deletion behavior (default keep_notebook=False), and the return fields including notebook_id=None when deleted. It exposes the primary side effect (notebook deletion) clearly.
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 efficiently structured: a one-line summary, numbered steps, and a compact return block. Every line adds value, and the format makes the workflow easy to follow without fluff.
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 composite tool with 4 parameters and multiple side effects, the description is highly complete. It covers the full workflow, default behavior, deletion consequences, and the return structure in detail—especially valuable given the lack of annotation support and zero schema descriptions.
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%, but the description adds meaning for all four parameters: 'topic' seeds research, 'questions' drives notebook_query, 'max_sources' controls how many URLs are imported, and 'keep_notebook' determines deletion. This compensates well for the schema's lack of descriptions.
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 a composite workflow: create ephemeral notebook, research, import sources, and answer questions. It uses specific verbs and resource names, and the 'One-shot' framing distinguishes it from granular sibling tools like research_start and notebook_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use this tool: as a one-shot wrapper for a multi-step research and Q&A workflow. It does not explicitly state when not to use it or mention alternatives for more granular control, but the intended context is clear.
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:

[![notebooklm-mcp-lisa MCP server](https://glama.ai/mcp/servers/gracelee087/notebooklm-mcp-lisa/badges/card.svg)](https://glama.ai/mcp/servers/gracelee087/notebooklm-mcp-lisa)

Score Badge

Copy to your README.md:

[![notebooklm-mcp-lisa MCP server](https://glama.ai/mcp/servers/gracelee087/notebooklm-mcp-lisa/badges/score.svg)](https://glama.ai/mcp/servers/gracelee087/notebooklm-mcp-lisa)

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/gracelee087/notebooklm-mcp-lisa'

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