Description Engineering Is Not Copywriting: The Most Important Sentence Your Company Writes

A research team at Oxford wasn't studying branding. They were studying bias.

In 2025, Thierry Blankenstein, Jialin Yu, and their colleagues published BiasBusters — a study testing how different elements of tool listings affected which tools LLMs recommended. They tested seven models including GPT-4, Claude, Gemini, and DeepSeek. They changed names. They changed positions. They changed descriptions.

The result that should keep every product team awake: scrambling tool descriptions shifted recommendation distributions by a Total Variation of up to 0.45. That was the largest single factor measured. Larger than catalog position. Larger than pre-training exposure. Larger than the tool's name.

The researchers were measuring unfairness. What they accidentally quantified was influence.

Your Description Is Your Brand (To Machines)

A tool name is 1–3 tokens. A description is 20–100 tokens. When an attention-based model processes your listing, it has 10–100x more information in the description to form connections with whatever query triggered the search.

Think about what that means. An agent looking for "a tool to monitor API health" finds the tokens "monitors," "API," and "health" directly in a good description. The name — whether it's "Assay" or "Sentinel" or "Keld" — has indirect or zero attention connections to that query.

The description IS the brand, as far as the machine is concerned. The name is a label on the package. The description is the package itself.

This isn't copywriting. Copywriting persuades humans. Description engineering makes you findable by machines. The skill set is different, the constraints are different, and the feedback loops are faster.

The State of Descriptions Today Is Embarrassing

Browse any MCP server directory or npm registry and you'll find descriptions like these:

"Useful helper tool."

"Interact with the service API."

"A general-purpose tool for various operations."

If you've built tools, you've written descriptions like these. Every developer has. Each one renders the tool invisible to machine cognition. An agent searching for "convert PDF to markdown" has zero semantic overlap with "useful helper tool."

Now compare:

"Convert PDF documents to clean Markdown. Preserves headings, tables, lists, and code blocks. Handles scanned PDFs via OCR. Returns structured Markdown suitable for AI pipelines, documentation systems, and content management."

Every clause creates a matching surface. "Convert PDF" matches the query. "Clean Markdown" matches the format need. "Preserves headings, tables" matches the structure requirement. "Handles scanned PDFs" matches the edge case. "AI pipelines" matches the use context.

The difference isn't literary quality. It's discoverability. The first description makes your tool invisible. The second makes it findable for a dozen different query formulations.

The Frame Is the Message

Behavioral economics gives us the framing effect: the same fact, presented differently, produces different decisions. "Prevents 95% of attacks" makes you feel safe. "Lets 5% of attacks through" makes you nervous. Same number. Different frame. Different decision.

When a model reads your description and synthesizes a recommendation, the words you chose — the order, the emphasis, what you led with — shape how it presents you.

"Monitors API health and alerts before failures impact users" frames you as proactive. "Detects API failures after they occur" frames you as reactive. Both could describe the same product. Only one gets selected when an agent is optimizing for reliability.

Here's the critical difference from writing copy for a landing page: when a person reads your website, they bring their own context, skepticism, and ability to evaluate independently. When a model reads your description, the frame is the evaluation. It doesn't visit your site. It doesn't try a demo. It reads the description, computes the match, and makes a selection.

The frame you set is the frame that sticks.

The What-How-When Pattern

Across MCP tools, package registries, README files, and website meta descriptions, the same structure works:

1. First sentence: what it does (action verb + object)
2. Second sentence: how specifically (capabilities, differentiators)
3. Third sentence: when to use it (contexts, use cases)

This pattern works because it mirrors how models process tool selection. The "what" creates the primary embedding match. The "how" refines the match against specific requirements. The "when" helps the model distinguish your tool from similar alternatives.

Multi-Surface Descriptions

The same product needs different descriptions for different contexts. Each surface has its own constraints:

• MCP tools: 1–3 sentences. Every excess token taxes the agent's context window. Be surgical.
• Package registries (npm/PyPI): 2–4 sentences. This is Tier 1 training data — future model training runs will ingest it. Every co-occurrence between your brand name and target concepts is being programmed into future models.
• llms.txt: Full control, structured for extraction. Problem/Solution/Capabilities/When to Use maps directly to agent queries.
• README: The first 200 words matter disproportionately. They appear in search results, social previews, and are the most frequently crawled section.
• Website meta descriptions: Both an SEO signal and training data. Every crawler that captures your page carries this description into potential training corpora.

One description doesn't fit all. But they should all tell the same story with different levels of detail.

What Description Engineering Is Not

It's not keyword stuffing. The temptation is to cram every synonym into the description: "Monitors (tracks, observes) external API health (availability, reliability, uptime)." Practitioners who review production tool catalogs will tell you this is actively harmful.

Overloading with synonyms creates noise, not signal. The embedding model averages across all tokens. Synonym-stuffed descriptions become a diffuse average of vaguely related terms rather than a precise representation of what the tool actually does.

The correct approach is specificity. Write one clear description of each capability. Use the most common, most precise term. Semantic proximity handles the rest — "monitors API health" is already close enough to "tracks API availability" in embedding space.

The parallel to SEO history is instructive. Early search engines rewarded keyword stuffing. Google destroyed that strategy. The same cycle will play out with description engineering. Today, well-crafted descriptions have a significant advantage because most descriptions are terrible. As the field matures, the advantage will narrow.

The brands that survive will be the ones whose descriptions accurately represent genuinely capable products. Description engineering makes you findable. Product quality makes you recommendable. You need both.

The Description-First Strategy

Here's an approach that feels backwards: write the description before finalizing the name.

If the description is "Audits websites, APIs, and CLIs from an outside perspective — finds security holes, UX friction, and accessibility failures that builders can't see," then the name should reinforce "audits," "outside perspective," "finds," or "can't see."

This inversion is psychologically difficult. Naming feels like the creative decision. Description-writing feels like filling out a form. But the research is clear about which carries more weight for machine cognition.

Starting with the description ensures the highest-leverage element gets the most creative attention.

The Three-Question Test

Find your product's description — on npm, your GitHub README, your website meta tag, or your MCP tool manifest. Then answer:

1. List five queries an agent would use to find your product. Does your description contain the key concepts from at least three of them?
2. Read it as if you'd never heard of your product. Do you know what it does after the first sentence?
3. Compare it to your closest competitor's. Which is more specific?

If you answered "no" to any of these, you've found the highest-leverage brand optimization available to you right now. Rewrite it. The name took weeks. The description matters more.

---

Description engineering is one layer of what we call Meaning Engine Optimization — the discipline of building brands that work for both human and machine cognition. Learn more about the MEO framework →