datasheet-lens

Overview Schema Source Related Servers Discussions Admin

search_text

Find text in datasheet PDFs to locate the page, table, figure, or region for a register, parameter, or pin; then open that page image to verify the value in the original.

Instructions

Find a text in the text layer of one document, or of all documents of a part. Gives one line for each hit: the document reference, the page, the table or figure that holds the line (an element ID) or the region of the line, and the line. Give the element or the region to get_page_image: it costs less than a full page. The page headers and footers are not shown: a last line gives their number. Use it to find the page of a register, a parameter or a pin. Then read the value from the original (get_page_image): the text layer can be wrong.

Input Schema

Name	Required	Description	Default
`mode`	No	text (a substring); word (whole words only: "nF" does not find "configuration"); or regex (a Python regular expression, for example "Pin Functions?").	text
`part`	No	A part number (MPN) or an alias. Case is ignored.
`text`	Yes	The text to find. Case is ignored. In mode text it is a substring ("VDD" also finds "AVDD"), and the space between a number and its unit is optional ("100 nF" also finds "100nF").
`document`	No	The document: its reference from list_documents, project_status or add_document (the first 12 characters of its SHA-256). A longer SHA-256 prefix or the numeric document ID also works.
`repeated`	No	True: also the lines that repeat on many pages (page headers and footers).
`max_lines`	No	The maximum number of lines (1 to 200).

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does: it discloses result format, the element/region handle, that page headers/footers are suppressed unless repeated=true with a count on the last line, the cost advantage of region-targeted image reads, and the important caveat that 'the text layer can be wrong' so values should be confirmed on the original. That is more behavioral context than most definitions supply.

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?

Front-loaded, but the prose is loose and repeatedly broken mid-sentence by hard line breaks ('a\npart', 'their\nnumber'), which reads like unflattened wrapping and costs clarity. The header/footer note and the get_page_image advice are valuable but could be tightened.

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?

An output schema exists, and the description still summarizes the hit format and the accuracy caveat, so an agent can act without inspecting the schema. Annotations are absent, but the read-only nature is implied by 'find'; nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so mode, repeated, max_lines and text semantics are already documented in the schema. The description only adds the downstream meaning of the element/region output and the header/footer suppression tied to repeated, so the baseline 3 applies.

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 specific verb and resource ('find a text in the text layer') and scopes it precisely: one document, or all documents of a part. It also previews the return shape (document ref, page, element or region, line). It does not explicitly contrast with the sibling get_element_text, which is the nearest look-alike.

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?

Gives a concrete use case ('find the page of a register, a parameter or a pin') and a follow-up path ('Give the element or the region to get_page_image'). It doesn't state exclusions, e.g. when list_items or get_element_text is the better entry point.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.