Facts about Micah Boswell, product design leader in Dallas: work, writing, photography, profiles.
Scored across 9 tools
Most tools target distinct facets (photography, poem, profiles, work, writing), but about_micah_boswell and micah_boswell_facts overlap heavily—both return biographical summary content, and an agent may not know which to pick for a general 'who is this' query. The writing/poem pair is well-linked and clearly distinguished.
All names are snake_case and readable, with a dominant 'micah_boswell_' prefix on seven tools. Two tools (about_micah_boswell, search_micah_boswell) use a verb-first pattern instead, a minor but noticeable deviation.
Nine tools is well within a sensible range and each covers a distinct content area (facts, FAQ, photography, poems, profiles, work, writing, search). No tool feels redundant in count terms.
The surface covers identity, structured facts, FAQ, work history, writing, poems, photography, and full-text search—strong lifecycle coverage for a personal-info server. Minor gaps: contact/profile retrieval is folded into facts rather than exposed directly, and no dedicated tool for film/speaking despite being mentioned.
One paragraph about Micah Boswell, product design leader in Dallas, Texas, followed by a short list of key facts: role at AT&T, awards, origins, education, mentoring, photography, writing, canonical URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover read-only, idempotent, non-destructive behavior, lowering the burden on the description. The description adds useful context beyond those annotations by specifying the exact result structure (paragraph plus key-fact list) and the topics covered, which helps the agent set output expectations.
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?
The description is a single, information-dense sentence with no filler. The core result ('one paragraph... followed by a short list') is front-loaded, and the enumerated fact categories are concise and immediately useful.
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 parameterless, read-only profile tool, the description adequately conveys what the agent will receive and which content areas are covered. It stops short of detailing how the facts are formatted or ordered, but that is not essential for correct selection and invocation.
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?
The tool has zero parameters, so the schema already provides complete coverage and parameter semantics are not a concern. The description does not need to explain parameters and correctly focuses on the static output content.
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?
The description clearly identifies the resource (Micah Boswell) and the output shape: one overview paragraph plus a fact list. The listed content categories and sibling names make it distinguishable from micah_boswell_facts, micah_boswell_faq, and other dedicated tools, though it lacks an explicit action verb like 'returns' or 'displays'.
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?
Usage is implied by the title and content description: an agent would use this for a general profile or overview of Micah Boswell. However, there is no explicit statement about when to choose this over sibling tools such as micah_boswell_facts or micah_boswell_profiles, and no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The complete structured facts record as JSON: identity, now, work timeline, education, certifications, awards, mentoring, photography, writing, film, speaking, side projects, profiles, disambiguation, citation guidance, contact, FAQ.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds useful context about the response being a complete structured JSON record, but it does not disclose additional behavior such as response size, freshness, or any limitation of the 'complete' claim. There is no contradiction with the annotations.
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?
The core statement 'The complete structured facts record as JSON' is front-loaded, and the trailing list of content categories is information-dense. The list is long but earns its place by mapping the tool's scope, even though it reads as a single run-on sentence.
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?
There is no output schema, so the description must communicate what the tool returns; it does this by naming the format and the major fact categories. For a zero-parameter, read-only, idempotent tool, this is sufficient for an agent to select and invoke it correctly. It does not show the exact JSON structure, but the literal category list provides adequate completeness.
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?
With zero parameters, there is no parameter behavior to explain, so the baseline of 4 applies. The description instead clarifies what the returned record contains, which is more useful than param docs would be in this case.
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?
The description clearly identifies the tool as returning 'The complete structured facts record as JSON' and enumerates the covered topics, so an agent can tell it is a broad, structured facts reference rather than a narrative about page. It lacks an explicit verb like 'returns' or 'fetches,' and it does not explicitly distinguish itself from about_micah_boswell, but the structured JSON framing is fairly specific.
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?
The phrase 'complete structured facts record' implies the tool is the comprehensive reference for biographical and factual data, while siblings like micah_boswell_photography or micah_boswell_writing are specialized subsets. However, the description does not explicitly state when to prefer this tool over about_micah_boswell or micah_boswell_faq, nor does it name any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Question and answer pairs from micahboswell.design (home, mentoring, photography). Optional keyword query filters them; leave empty for all sixteen.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Keywords to filter by, e.g. "unsplash", "mentoring", "contact" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description usefully discloses that the corpus is a small fixed set of sixteen items, consistent with openWorldHint=false, but adds nothing about matching behavior, partial matches, or return shape.
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?
One sentence plus a parenthetical, front-loaded with what the tool returns, then scope, then parameter behavior. No filler or restated boilerplate.
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 single optional-string, read-only lookup with full annotation coverage, the description conveys the resource, the scope, the default behavior, and the corpus size. Return format is only implied by 'question and answer pairs', which is a minor gap given there is no output schema.
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% and the schema already supplies the example keywords, so baseline is 3. The description adds meaning beyond the schema by specifying the default semantics of an omitted query (return all sixteen), which is behaviorally important for an agent deciding whether to pass the parameter.
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 resource (question and answer pairs) and narrows the corpus to three named areas of micahboswell.design, with a concrete size of sixteen items. It does not explicitly contrast itself with siblings like micah_boswell_facts or search_micah_boswell, so the agent must infer the boundary.
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?
Gives clear operational guidance for the one parameter: an optional keyword query filters, and leaving it empty returns all sixteen. It does not name an alternative tool for broader site search, so the when-to-use-this-vs-siblings question is only partly answered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unsplash statistics (104 photographs, 53,380,492 views, 362,001 downloads, top 10 percent of contributors, 6 collections) and the most viewed photographs with title, URL and views.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many top photographs to return (1 to 24, default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful output specifics (statistics and photo fields) without contradicting the annotations, but it does not disclose any additional behavioral details such as sorting behavior or data staleness.
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?
The description is a single compact sentence that front-loads the tool's purpose and includes concrete statistics. The parenthetical list is somewhat dense, but every part contributes to understanding the output.
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 simple read-only tool with one optional parameter and no output schema, the description adequately describes the return content: statistics and top photographs with title, URL, and views. The limit parameter is fully specified in the schema, so nothing critical is missing.
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 100%, and the limit parameter is already fully documented with range and default values. The description does not mention the parameter, but the schema carries the full burden, so the baseline score of 3 is appropriate.
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?
The description clearly identifies the resource (Micah Boswell's photography on Unsplash) and the specific output: statistics plus the most-viewed photographs with title, URL, and views. It is specific enough to distinguish from sibling tools like micah_boswell_facts or micah_boswell_work, though it does not explicitly contrast itself with them.
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?
The description states what the tool returns but gives no guidance on when to choose this tool over alternatives such as search_micah_boswell or micah_boswell_work. It does not mention any exclusions, prerequisites, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one poem live from https://conscious-shell.com/poems/ and return its title and full text (from the page's CreativeWork JSON-LD). Slugs come from micah_boswell_writing, for example "dreams", "nova", "simpler-in-lima". Errors clearly when the slug does not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Poem slug, the last path segment of the poem URL, e.g. "dreams" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent safety, so the description doesn't need to repeat that. It adds valuable behavioral detail: the fetch is live, data is extracted from CreativeWork JSON-LD, and nonexistent slugs produce clear errors.
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 sentences cover the operation, URL pattern, return shape, data source, slug provenance, examples, and error behavior with zero filler. The core action is front-loaded and every sentence earns its place.
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 one-parameter read-only fetch with no output schema, this describes exactly what to call, where to get the input, what the response contains, and what happens on failure. Nothing essential is missing for an agent to invoke it correctly.
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?
The schema already documents the slug parameter at 100% coverage, so the baseline is 3. The description adds meaning beyond the schema by specifying that valid slugs come from micah_boswell_writing and providing concrete examples like 'dreams', 'nova', and 'simpler-in-lima'.
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?
The description names the exact resource (a single poem at a specific URL), the verb (Fetch), and the return payload (title and full text). It also distinguishes itself from micah_boswell_writing by explaining that slugs originate from that sibling tool, leaving no ambiguity.
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?
It clearly implies the intended workflow: get a slug from micah_boswell_writing, then use this tool to fetch that poem's full text, with concrete examples. It does not explicitly state when not to use it or name alternatives like search_micah_boswell, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every profile that belongs to this Micah Boswell (the schema.org sameAs list) with a label for each. A profile not on this list belongs to a different person with the same name.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful source context (schema.org sameAs list) and clarifies that each entry has a label, reinforcing the closed-world completeness implied by openWorldHint=false without contradicting any annotation.
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 concise sentences fully describe the tool's output and its key disambiguation rule. There is no redundant information, and the scope is front-loaded before the exclusion statement.
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 zero-parameter read-only list tool, the description is complete: it states what is returned, how profiles are sourced, and how to interpret profiles not in the list. No output schema exists, but the description adequately conveys the return shape without requiring further detail.
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?
The tool has zero parameters, so there is no parameter semantic burden for the description. With no inputs to document, the description correctly focuses on output scope instead.
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?
The description clearly identifies the resource as verified profiles belonging to this specific Micah Boswell and explains the scope via the schema.org sameAs list. It does not use an explicit action verb like 'lists' or 'returns', but the meaning is unambiguous and it differentiates from sibling search tools by defining what is not included.
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?
The description gives clear context for when this tool is relevant: it provides the authoritative list of profiles for this person. The statement 'A profile not on this list belongs to a different person with the same name' acts as a disambiguation rule, though it does not name sibling alternatives like search_micah_boswell explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Roles from 1998 to now, most recent first: title, organization, years. Includes the current AT&T work, measured impact, and the case studies URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond annotations: ordering (most recent first), time span, and content specifics, helping an agent understand what the tool returns.
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?
The description is exactly two sentences with no wasted words. It front-loads the core purpose and ordering, then adds necessary details. Every sentence earns its place.
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?
With no output schema, the description carries the full burden of return-format explanation. It clearly specifies the fields, ordering, and additional included content (AT&T work, measured impact, case studies URL), which is sufficient for an agent to call the tool and interpret the result.
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?
The tool has zero parameters, so the baseline of 4 applies. The description compensates for the lack of an output schema by detailing the return fields (title, organization, years) and included items.
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?
The description clearly states the tool lists roles with title, organization, years, ordered most recent first, spanning 1998 to now. This specificity distinguishes it from sibling tools like photography, poem, faq, and profiles, making its purpose unmistakable.
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?
The description gives clear context that this is a work timeline tool and mentions specific content like current AT&T work, measured impact, and case studies URL. It does not explicitly name alternatives or exclusions, but the context strongly implies when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Essays at conscious-shell.com with URLs and summaries, all 29 poems with URLs and slugs (pass a slug to micah_boswell_poem to read one), plus Medium, LinkedIn articles, Quora, and dev.to.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful context that this tool provides URLs, summaries, and slugs rather than full article text, which clarifies expected output without needing to restate safety hints.
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?
The description is one dense sentence with no filler. Every clause adds distinct information about content types, URLs, summaries, slugs, or the related poem tool, making it highly efficient.
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 zero-parameter read-only index, the description covers the main content buckets and points to the correct sibling for reading poems. It is slightly ambiguous whether the trailing platforms also come with URLs and summaries, but this is a minor gap given the tool's simplicity.
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?
The input schema is empty with zero parameters, so there are no parameter semantics to explain. A baseline of 4 is appropriate for a no-parameter tool where the schema has already covered everything.
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?
The description clearly inventories the tool's content: essays with URLs/summaries, all 29 poems with URLs/slugs, and additional platforms like Medium, LinkedIn, Quora, and dev.to. It also distinguishes itself from micah_boswell_poem by naming that sibling, though it lacks an explicit verb like 'lists' or 'returns'.
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?
It explicitly tells the agent to pass a slug to micah_boswell_poem to read a poem, providing clear routing guidance for poem content. It does not discuss when to prefer this tool over search_micah_boswell or micah_boswell_profiles, so it is not fully comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search over the full text of micahboswell.design (llms-full.txt) and the conscious-shell.com summary. Returns matching paragraphs with the page URL each came from, best matches first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum paragraphs to return (default 8) | |
| query | Yes | Words to look for, e.g. "Lima Peru", "GE Nuclear", "Agentic framework" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile needs no restating. The description adds genuinely useful behavior beyond that: the ranking rule ('best matches first') and the shape of a result (matching paragraphs tagged with their source page URL), but says nothing about index coverage limits or relevance caveats.
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 zero padding, front-loading what is searched before what comes back. Every clause carries information an agent needs.
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?
With no output schema, the description correctly takes on the return-value burden (matching paragraphs plus originating page URL, ranked). Only minor omissions remain, such as what happens on zero matches or whether the index is exhaustive, which for a low-complexity two-parameter read tool is acceptable.
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 100% – both query (with examples and length bounds) and limit (default 8, max 25) are documented in the schema itself. The description adds no additional parameter meaning, so the baseline of 3 applies.
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 (keyword search) and the exact corpus it covers (micahboswell.design llms-full.txt plus the conscious-shell.com summary), plus what it returns. It is clearly a full-text search rather than a structured lookup, so it is distinguishable from the sibling fact/FAQ/profile tools, though it never names a sibling explicitly.
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?
Usage is only implied: 'keyword search over the full text' suggests reaching for it when you have free-text terms rather than a known fact/facet. There is no explicit when-to-use, when-not-to-use, or routing guidance against the eight siblings (micah_boswell_facts, micah_boswell_faq, etc.), and the title's 'search everything' phrasing could actively mislead an agent into preferring it over the structured tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
about_micah_boswellmicah_boswell_factsmicah_boswell_faqmicah_boswell_photographymicah_boswell_poemmicah_boswell_profilesmicah_boswell_workmicah_boswell_writingsearch_micah_boswellRead-only facts from brentburgess.com: profile, writing, projects and the site's own datasets.
Bo Kendell's portfolio: projects, writing, work history, resume, and live activity.
An interactive portfolio built for AI conversations. Browse work, services, and book calls.
Authored design service: one-of-one landing pages, pitch decks, and research-grounded briefs.
Add one secure layer between your agents and this server.
