Facts about Micah Boswell, product design leader in Dallas: work history, writing and poems, Unsplash photography stats, mentoring, verified profiles, FAQ. Streamable HTTP, no auth.
Scored across 9 tools
Most tools map to a distinct content type (facts, FAQ, photography, poems, profiles, work, writing, search). There is minor overlap between about_micah_boswell, micah_boswell_facts, and micah_boswell_work since all contain biographical information, but their descriptions clarify different levels of detail.
Eight of nine tools follow the same micah_boswell_<topic> snake_case pattern, making the domain clear and predictable. search_micah_boswell breaks the noun pattern with a verb prefix, but it is still consistent in style and clearly signals its different function.
Nine tools is well-scoped for a personal knowledge server covering a single individual. Each tool addresses a meaningful content area, and none feel redundant or unnecessary.
The tool surface covers the main facets of the personal knowledge domain: identity, career, writing, poetry, photography, profiles, FAQ, and full-text search. The structured facts record also includes contact, citation guidance, and FAQ content, so there are no obvious dead ends.
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.vercel.app (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 cover the read-only, idempotent, non-destructive safety profile, lowering the burden on the description. The description adds useful retrieval behavior: the source and page scope, the optional keyword filter, and the exact default cardinality of all sixteen Q&A pairs.
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 entire description is one compact sentence that moves from resource to filter behavior to default behavior without filler. Every clause contributes information needed to invoke the tool correctly.
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-optional-parameter, read-only tool with no output schema, the description fully covers what is returned, where it comes from, how to filter it, and what happens when the query is empty. No critical invocation information 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?
The input schema already covers the single query parameter at 100%, including concrete examples, so the baseline is 3. The description reinforces that the parameter is an optional filter and adds the empty-query default, but it does not introduce new semantics like matching rules or output formatting.
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 (Q&A pairs from specific site sections) and the filtering behavior, so it is not a tautology. It lacks an explicit verb like 'retrieves' and does not differentiate itself from siblings such as search_micah_boswell, so it does not fully earn a 5.
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 only usage guidance is for the query parameter: optional keywords filter the results, and leaving it empty returns all sixteen. There is no statement about when to prefer this tool over the sibling content or search tools, so tool selection is left mostly to inference from the name and content.
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.vercel.app (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?
With annotations already declaring readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds useful behavioral detail beyond those: it specifies the search corpus, that results are matching paragraphs, that each result includes the page URL, and that results are ordered best matches first. This is strong disclosure for a safe, read-only search tool.
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 two concise sentences with no filler. It front-loads the primary action and resource, then immediately provides the output shape and ordering. Every word 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 simple read-only search tool with two well-documented parameters and no output schema, the description is nearly complete. It covers source, output format, URL association, and ranking. Minor omissions like matching semantics or pagination details are not critical given the tool's low 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 100%, so the schema fully documents both parameters: query and limit. The description does not add parameter-specific meaning beyond what the schema already provides, so baseline 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 uses a specific verb ('Keyword search') and identifies the exact resource being searched: the full text of micahboswell.vercel.app (llms-full.txt) and the conscious-shell.com summary. This clearly distinguishes it from sibling tools like about_micah_boswell or micah_boswell_facts, which are focused on specific content areas rather than full-text retrieval.
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 implies usage: an agent should invoke this when a keyword/query-based search across all content is needed. However, it does not explicitly state when to prefer this over a sibling or when not to use it. The 'full text' framing gives context, but no alternatives or exclusions are mentioned.
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_boswell
Add one secure layer between your agents and this server.