Ryan Lindsey's professional corpus, exposed as MCP tools.
Scored across 8 tools
Each tool targets a distinct resource type: case studies, posts, resume, contact, search, and access requests. There is no overlap between get vs list vs search operations, and content types are clearly separated.
All tools follow a consistent verb_noun pattern in lowercase snake_case: get_case_study, list_writing, search_writing, request_private_access. The naming is uniform and predictable across the entire set.
Eight tools is an appropriate size for a personal content server, covering retrieval, listing, search, contact, and access info without unnecessary redundancy. Each tool earns its place in the set.
The server fully covers the read-only content lifecycle: listing and fetching posts and case studies, retrieving the resume, searching across all content, and obtaining contact/access information. No significant gaps exist for the stated personal portfolio use case.
The full markdown of one published case study, by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The slug from list_case_studies. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden alone. It discloses the return format ('full markdown'), the availability filter ('published'), and the lookup key ('slug'), but does not mention error behavior, read-only guarantees, or what happens for unpublished/private slugs.
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 short, front-loaded sentence that conveys resource, scope, and return format without wasted words.
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 one-parameter read tool, the description is largely complete: it names the input, the resource type, and the output format. Minor gaps around not-found/error handling and private-access behavior exist, but they are not critical for basic 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?
Schema description coverage is 100%, so the schema already documents the slug parameter. The description only restates the slug mechanism and adds the 'published case study' context, which is useful but does not significantly go beyond 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?
The description clearly identifies a single resource ('one published case study'), the return format ('full markdown'), and the lookup mechanism ('by slug'). It is easily distinguished from siblings like list_case_studies, get_post, and get_resume.
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 when to use the tool: when you have a slug and need the full markdown of one published case study. It does not explicitly state alternatives, exclusions, or the need to first call list_case_studies to obtain the slug, though the schema property description covers that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How to reach Ryan Lindsey, and his working timezone.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It does disclose the substantive output—how to reach Ryan Lindsey and his working timezone—but it does not mention response format, whether the information is public, or any privacy or rate-limit considerations.
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?
A single, compact sentence conveys the essential content with no filler. The key information—person and data scope—is immediately visible.
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, no-output-schema tool, the description is reasonably complete: an agent can infer what the tool returns and why it exists. It could be more explicit about what 'how to reach' includes, but the low complexity makes this a minor gap.
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 fully covers invocation. The description does not need to explain parameter meaning; the baseline of 4 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?
The description clearly identifies the tool's subject (Ryan Lindsey) and what it provides: contact methods and a working timezone. It is not a tautology, and the resource distinguishes it from content-oriented siblings, though it lacks an explicit retrieval verb.
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?
There is no guidance about when to use this tool versus alternatives like request_private_access or search_writing. The only implied context is that contact information is being sought, but no exclusions or selection conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full markdown of one published post, by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The slug from list_writing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It states the core behavior—returning the full markdown of a published post—but does not disclose error behavior, access restrictions, or explicitly confirm a read-only side-effect profile beyond the implied 'get'.
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 short, front-loaded sentence with no filler. Every word contributes to understanding the resource, the scope, and the lookup mechanism.
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?
This is a low-complexity single-parameter getter with no output schema and no annotations. The description adequately states what is returned and how to identify the target post, making it sufficient for normal use; minor gaps remain around error handling and access behavior.
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 schema already explains 'slug' as 'The slug from list_writing'. The description's phrase 'by slug' adds no new semantic detail beyond what the schema provides, so the baseline score 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?
The description clearly identifies the resource as a single published post and the lookup key as the slug. This distinguishes it from sibling tools like get_case_study, get_contact, and get_resume, which target different resources.
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 context is implied rather than explicit: the schema notes that slug comes from list_writing, suggesting an agent should list posts first. However, the description does not explicitly state when this tool should be preferred over search_writing or other getters, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ryan Lindsey's résumé: JSON Resume data, the published markdown document, or a short prose summary.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | json = JSON Resume schema; markdown = the published document; summary = a short prose read. | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It discloses that the tool returns a résumé in one of three formats, but it adds little beyond that and does not mention default behavior, side effects, access constraints, or output shape beyond the format enum.
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 front-loaded sentence that immediately identifies the resource and then lists the three format options compactly. There is no filler, redundancy, or unnecessary background.
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 tool, the description plus a fully covered input schema is sufficient for an agent to invoke it correctly. An explicit statement of the default format would be a minor addition, but the schema already provides the default and enum meanings.
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%; the enum descriptions already define the three formats. The description essentially restates those options in prose, adding no new semantics beyond tying them to Ryan Lindsey's résumé. The baseline 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 names the specific resource ('Ryan Lindsey's résumé') and the three concrete representations it can return, which is specific enough to distinguish it from sibling tools like get_case_study or get_contact. The verb 'get' plus the resource is clear and actionable.
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?
No explicit when-to-use guidance or alternatives are mentioned; the agent must infer from the resource name that this tool is for résumé requests. The description gives clear context that it returns Ryan Lindsey's résumé, but it does not state when to choose it over sibling 'get' tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Published case studies with their metadata and citation URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the data returned. It does not disclose whether the operation is read-only, requires auth, paginates, filters, or what happens for empty results.
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 10-word phrase with no filler. Everything present ('Published', 'metadata', 'citation URLs') adds information beyond the title.
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 list operation, the description is minimally adequate: it names the resource and the kind of return data. However, with no output schema and no annotations, it leaves return-shape details and usage-vs-sibling decisions unspecified.
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 and the input schema documents this completely, so there is no parameter burden for the description to carry. The baseline of 4 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?
The title and name supply the verb ('List') and resource ('case studies'), and the description adds the scope 'Published' plus what is returned (metadata and citation URLs). It is clear enough to distinguish from the singular get_case_study and list_writing, but it does not explicitly call out any sibling or contrast.
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?
No guidance is given on when to call this tool instead of get_case_study, search_writing, or list_writing. The only clue is the plural 'list' naming, which is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Published posts with their descriptions and citation URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It adds useful scope ('published') and result content, but it does not disclose read-only behavior, ordering, pagination, or authorization needs. This is minimally adequate for a simple list tool, but not rich.
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 short fragment with no filler; every word contributes to the resource and output fields. It is appropriately sized and front-loaded for a zero-parameter tool.
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 no-argument list tool, the description is nearly complete: invocation requires no input, and the description states what is returned. However, with no output schema or annotations, it could better distinguish this from siblings and mention ordering or pagination.
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 has zero parameters and 100% schema coverage, so the baseline of 4 applies. There is no parameter semantics for the description to add beyond the empty 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?
The description clearly identifies the resource ('published posts') and the fields that will appear ('descriptions and citation URLs'), so an agent can infer this is a listing tool for writing content. However, it lacks an explicit verb and does not differentiate itself from siblings like search_writing or get_post.
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?
There is no guidance about when to use this tool versus search_writing or get_post, and no exclusions or prerequisites are mentioned. The phrase 'Published posts' implies a usage context, but the description never states a selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains the private access tier and how to request a scoped token.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It hints the tool is informational ('Explains') but does not clarify whether calling it actually requests or issues a scoped token, what the response looks like, or whether any side effects or authentication prerequisites exist.
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?
A single, direct sentence with no filler. The core idea is front-loaded and the description is appropriately sized for the tool's simplicity.
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 0-parameter tool, the description gives the gist but leaves uncertainty about output format and whether the tool actually performs the request or merely provides instructions. An agent could not confidently predict the result of invoking it.
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 and schema coverage is 100%, so there is nothing for the description to add beyond what the schema already shows. Baseline for zero params is 4.
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 states a specific action ('Explains the private access tier') and object ('how to request a scoped token'), which distinguishes it from the sibling data-retrieval tools. However, the tool name 'request_private_access' implies an actual request action while the description says 'explains', creating slight ambiguity about whether it performs the request or only describes it.
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?
No explicit when-to-use guidance or comparison to alternatives is provided. From the sibling names, an agent can infer this is the only non-data-retrieval tool, but the description never states when an agent should call this versus using existing access or another tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search across the published posts, case studies and résumé. Each result is a passage, the URL it is published at, and an "exact" flag saying whether the excerpt is the passage that matched.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many passages to return. Defaults to 5. | |
| query | Yes | What to look for, in natural language. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the result structure (passage, URL, 'exact' flag) and clarifies that matching is semantic rather than exact, which explains the flag's meaning. Minor omission: no mention of result ordering or relevance guarantees, but the core behavior is transparent.
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 with no filler. The purpose is front-loaded, and the result format explanation is concise and directly 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 simple search tool with no output schema and no annotations, the description covers the search scope and result contents. It lacks explicit ordering details or edge-case guidance, but it is complete enough for correct 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?
Schema coverage is 100%, so the baseline is 3. The description adds no parameter details beyond what the schema already provides for query and limit; it does not enhance understanding of argument semantics.
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 'Semantic search' with specific resources (published posts, case studies, résumé). Clearly distinguishes from siblings that retrieve or list items (e.g., get_post, list_writing) rather than search across 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?
Usage is implied: use when you need to find relevant passages across the blog, case studies, or résumé. However, no explicit when-not or alternative routing is given; the agent must infer from sibling names that this is the search tool.
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.
get_case_studyget_contactget_postget_resumelist_case_studieslist_writingrequest_private_accesssearch_writingPublic portfolio MCP for resume, services, availability, project evidence, and introductions.
Free MCP tools: the only MCP linter, health checks, cost estimation, and trust evaluation.
Security research: MCP registries verify identity, not tool behavior. See gtfo.dev.
Independent trust scores, tool surfaces and change history for MCP servers.
Add one secure layer between your agents and this server.
