embed_textText embeddings for RAG / semantic search: one string or up to 100 strings -> L2-normalised vectors with open BAAI models on Cloudflare GPUs: bge-small-en-v1.5 (384-d, English, default) or bge-m3 (1024-d, multilingual). Up to 24,000 characters per call. Paid ($0.0002, x402).
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Text or list of texts (a single string is also accepted) | |
| model | No | Embedding model to use |
Changes observed during successful MCP inspections.
Input schema / properties / model / descriptionAdded value: +"Embedding model to use"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint and openWorldHint, so the description carries the rest and does well: it discloses batch cap (100 strings), per-call character limit (24,000), model dimensions/languages, normalization, and a paid cost model via x402. The only gap is that the exact return structure is not described.
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?
Two dense sentences with no filler; the core purpose and the model/pricing specifics are front-loaded. Every clause (batch cap, char cap, cost) carries information, though the model enumeration makes it a touch crowded.
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 two-parameter tool with full schema coverage and no output schema, the description is nearly complete: it covers purpose, models, limits, and cost. It stops short of describing the response shape (e.g., an array of vectors per input), the one piece an agent must infer.
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 coverage is 100%, so 3 is the baseline, but the description adds real value by declaring bge-small-en-v1.5 the default and clarifying the input accepts a single string or a list. The default-value information is not present in the schema.
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 specific verb (produce embeddings) and resource (text), names the output artifact (L2-normalised vectors), and enumerates the two supported models with dimensions and languages. An agent immediately understands it is the embedding tool, and no sibling overlaps this space.
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?
Frames the intended use as 'RAG / semantic search' and gives concrete capacity guidance (one string or up to 100 strings), but offers no explicit when-to-use/when-not conditions or alternatives. Since no sibling tool competes for this task, the lack of exclusions is understandable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.