Generate a structured data table in NotebookLM from a notebook's sources. Provide notebook ID and optional extraction instructions to turn key information into tabular output.
Gera uma tabela de dados no NotebookLM.
| Name | Required | Description | Default |
|---|---|---|---|
| notebook_id | Yes | ||
| instructions | No | Extraia os dados principais em uma tabela. |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: not whether generation is synchronous or long-running, whether it requires existing sources, whether the table is persisted or returned, or any rate/cost considerations. Only the bare fact of creation is conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler or redundancy, and the action is front-loaded. The problem is under-specification rather than verbosity, so it is efficient but too thin to be genuinely well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generative tool with no annotations, two undocumented parameters, and no output schema, the description leaves nearly every question unanswered — input requirements, output form, and relationship to sibling generators. It is far from complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for either parameter. The agent gets no explanation of what notebook_id must reference or what the optional instructions field controls beyond its Portuguese default text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb and resource ("Gera uma tabela de dados") plus a scope ("no NotebookLM"), so the agent knows what action it performs. However, it offers no differentiation from sibling generators like generate_infographic, generate_mind_map, or generate_summary_report, all of which produce artifacts from notebook content. Purpose is intelligible but generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative guidance. The agent must infer from the name alone that this should be chosen over generate_infographic or generate_mind_map when tabular output is wanted, and nothing states prerequisites such as needing sources already added to the notebook.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.