Fit reports and search over Corey James's work: GPU inference, agent governance, enterprise AI.
Scored across 11 tools
Most tools are cleanly separated by resource and intent (list_* for enumerations, get_page for single-record fetch, contact for the only write action). The one soft overlap is between search_portfolio and match_role, which both return ranked pages with evidence, though match_role's requirement-by-requirement fit report is distinguishable. 'scale' vs 'who' vs 'list_systems' also brush against each other as overview tools but each returns different content.
The list_* family and get_page/search_portfolio/match_role follow a verb_noun pattern, but the set is broken up by bare verb 'contact' and bare nouns 'scale' and 'who', which don't announce their action or return type. It's readable but visibly mixed rather than a single convention.
Eleven tools is well within a comfortable range and each maps to a distinct slice of the portfolio surface: enumerations, a page fetch, discovery, orientation, and contact. Nothing appears redundant or padded.
The domain is a read-mostly portfolio site, and the surface covers orientation (who, scale), enumeration (systems, technologies, capabilities, ideas, patent applications), single-page retrieval, search, fit-matching, and the one write action (contact). Minor gap: there is no direct way to enumerate the engineering stories or arbitrary pages, so an agent must reach them via search_portfolio or get_page URLs it already knows.
Send a message to Corey James through the site's contact form, on behalf of the user. Requires the user's own name and email.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| Yes | |||
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that this is an outbound action to a named third party that transmits the user's personal name and email, which is meaningful privacy context. However, it says nothing about irreversible send behavior, confirmation, rate limits, or delivery outcome.
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 tight sentences; the action and recipient are front-loaded and the prerequisite (user's own name and email) follows. No filler.
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 three-field form-submission tool with no annotations and no output schema, the description covers who it contacts, on whose behalf, and what identity data is required. The main gap is what happens after submission (success/failure feedback), which would be helpful but is not essential to invoking 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?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'name' and 'email' are the user's own rather than the agent's — genuinely useful semantics — but leaves 'message' entirely unexplained (content, length, subject). Partial compensation only.
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 pairs a specific verb ('Send a message') with a specific resource and recipient ('to Corey James through the site's contact form'), plus the acting mode ('on behalf of the user'). All sibling tools are read/list/get operations, so an agent can immediately tell this is the one outbound-write tool in the set.
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 states the condition of use: sending a message to Corey on the user's behalf, and that the user's own identity data is needed. It does not state when not to use it or offer alternatives, but no sibling covers this capability, so there is nothing to disambiguate against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The record for one page by URL: title, result, systems, technologies, stats, lede, quote, evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden, and it discloses little beyond content: nothing about behavior on unknown/invalid URLs, whether the URL must be absolute, caching, auth, or rate limits. The field enumeration is useful, but it describes output shape rather than behavioral traits.
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 front-loaded phrase with zero waste; the identifying key and the returned fields are stated up front. It is a sentence fragment and the trailing field list is somewhat cryptic, but nothing is padding.
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 lookup with no output schema, the field enumeration partially substitutes for return-value documentation, which is a real contribution. However, URL format expectations and not-found/error behavior are absent, leaving gaps an agent would hit on first call.
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 0% for the single url parameter, so the description must compensate. 'By URL' establishes the parameter's identity role for the page, but adds no format, normalization, or example guidance for what is otherwise a bare string.
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 retrieval: one page identified by URL, and enumerates the returned fields (title, result, systems, technologies, stats, lede, quote, evidence). This clearly contrasts with the list_* siblings, which return many items rather than one record. Slightly terse phrasing ('The record for one page') keeps it from 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?
Use is implied rather than stated: 'one page by URL' suggests a single-item lookup in contrast to search_portfolio or list_* siblings, but no when-to-use, when-not-to-use, or alternative is named. An agent must infer selection criteria from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The capabilities the work demonstrates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Capabilities' weakly implies a read-only listing, but nothing is said about return shape, ordering, scope of 'the work', or whether results are exhaustive.
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?
It is a single short sentence with no waste, but it is under-specified rather than genuinely concise — it lacks a leading verb and any front-loaded scope information an agent could act on.
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 and no annotations, the description must explain what a call returns, but it only gestures at 'capabilities' with no indication of format or content. For an agent deciding whether this or list_systems answers its question, this is insufficient.
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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-related gaps exist.
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 is a noun fragment that largely restates the name 'list_capabilities' as 'the capabilities the work demonstrates' without a verb or scope. It hints at the domain (capabilities tied to a body of work) but never says it returns a list of them, nor distinguishes it from siblings like list_systems or list_technologies.
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 on when to use this tool versus the many sibling list_* tools (list_ideas, list_systems, list_technologies, list_patent_applications). No preconditions, no exclusions, no alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The recurring engineering principles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: not whether the call is read-only, not what an 'idea' record contains, not how results are ordered or bounded. The only behavioral hint is the implicit read semantics of the name 'list_ideas', which the description itself never confirms.
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 single short sentence is not verbose, but its brevity comes from under-specification rather than economy — it is a fragment that conveys almost no information. There is no front-loaded statement of what the tool does, because no such statement exists.
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?
Complexity is low (no parameters, no output schema), but the description still leaves the essential question unanswered: what an 'idea' is, what fields come back, and when to prefer this over the many sibling list tools. For a simple tool a single clarifying clause would have sufficed, and even that is absent.
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 takes zero parameters and the input schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies for a zero-parameter tool.
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 is a noun fragment ("The recurring engineering principles") that names a subject area but never states an action, so it never says the tool lists anything. It hints at the resource being 'ideas' but gives no verb and no differentiation from siblings like list_capabilities or list_systems — an agent cannot tell what this returns versus those.
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 when-to-use guidance, no exclusions, and no mention of any of the ten sibling tools. Nothing in the text tells an agent which situation should select list_ideas over list_capabilities, list_systems, or search_portfolio.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The provisional patent applications (patent pending), with application numbers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it does not disclose that this is a read-only listing operation, whether results are paginated, or what format the application numbers take. For a list tool with zero annotation coverage, this is a notable gap.
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, efficient sentence that front-loads the key resource. It is concise, though the lack of an explicit action verb makes it slightly less immediately actionable.
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?
Given the empty parameter schema and no output schema, the description should fully specify the tool's behavior. Instead it only names the data and does not confirm that the tool lists all provisional patent applications or describe any scoping or return 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?
The tool has zero parameters, so parameter semantics are not applicable. Per the rubric, a zero-parameter tool receives a baseline score of 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 identifies the resource (provisional patent applications with application numbers) but uses a noun phrase rather than a clear verb, so the agent must infer that this is a listing operation from the tool name alone. It does not explicitly distinguish the tool from sibling list tools such as list_ideas or list_technologies.
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 on when to use this tool versus alternatives like search_portfolio or list_ideas. The description merely states what data is included, leaving the agent to infer the applicable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The ten systems with one-line results.
| 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 burden and does not say whether results are ordered, truncated at ten by design or by default, what the one-line results contain, or whether any scope/permission applies. It only hints at a result limit and a terse output 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?
A single short sentence with no filler, which is good, but its brevity comes at the cost of specification rather than from efficiency—key facts about scope and ordering are simply absent.
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 tool with no output schema and no annotations, the description supplies the result count and a rough format, but omits what a system is, how results are ordered, and how the list relates to sibling list tools, so it is only minimally sufficient.
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 takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate; baseline 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 names the resource (systems) and adds a count (ten) plus an output format hint (one-line results), but it never states a verb and never says what a 'system' is in this portfolio context, leaving it partially tautological with the tool name.
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 on when to call this rather than the numerous sibling list tools (list_technologies, list_capabilities, list_ideas, list_patent_applications). The agent is left to guess whether 'systems' overlaps with those resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Technologies, optionally by kind (language, discipline, platform, framework, protocol, runtime, datastore, hardware, model).
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no read-only confirmation, no pagination/limit behavior, no ordering, and no indication of what happens with an unrecognized kind value. Only the implicit 'list' semantics give any signal.
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 compact sentence with no filler, and the essential enum list is placed where it can be scanned immediately. It is arguably under-specified rather than padded, so the terseness costs clarity slightly but wastes nothing.
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 list tool with no output schema and no annotations, the description covers the parameter domain but leaves the return shape and result size unaddressed. An agent knows the valid filter values but not what a call yields.
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 0% and the single 'kind' parameter has no description in the schema, so the description must compensate — and it does, enumerating nine valid values (language, discipline, platform, framework, protocol, runtime, datastore, hardware, model) that an agent could not otherwise know. It stops short of saying whether values are case-sensitive or whether other values are accepted.
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 resource ('Technologies') but supplies no verb; the read/list action is only inferable from the tool name list_technologies. The parenthetical enumeration of kinds is informative, yet the sentence never says what the tool actually does with them (enumerate matching entries).
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?
Only the phrase 'optionally by kind' hints at usage — it implies the filter is optional and unfiltered calls return everything. There is no statement of when to prefer this over sibling tools such as list_systems or list_capabilities, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a job description or a list of requirements, return an evidence-backed fit report: for each requirement, the pages and figures on coreyjames.ai that demonstrate it, plus the gaps. Cites, never asserts.
| Name | Required | Description | Default |
|---|---|---|---|
| requirements | Yes | A job description, or requirements one per line. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose meaningful behavior: output is a per-requirement fit report including both supporting evidence and gaps, and 'cites, never asserts' signals evidence grounding rather than generative claims. It does not explicitly confirm the operation is read-only or discuss limits on requirement volume, which keeps it short of a 5.
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, zero waste: the first front-loads the input-to-output contract, the second names the guarantees (evidence plus gaps, citations over assertions). Nothing could be removed without losing a distinct commitment.
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, annotation-free tool with no output schema, the description covers input shape, output structure, and evidentiary stance, which is close to complete. Minor gaps remain around whether the report covers all requirements when some cannot be evidenced and how gaps are presented.
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 single parameter already documents that it accepts a job description or requirements one per line. The description reinforces per-requirement granularity through 'for each requirement,' but adds no formatting, size, or syntax detail beyond the schema, 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 concrete input (job description or requirement list) and a concrete output (an evidence-backed fit report mapping each requirement to pages and figures, plus gaps). This is distinguishable from siblings like list_capabilities or search_portfolio, though those siblings are never named, so the differentiation is inferred rather than explicit.
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 'Given a job description or a list of requirements' implies the usage context, which is adequate for a single-purpose matching tool. However, there is no explicit when-to-use vs. when-not guidance and no mention of alternatives such as search_portfolio for ad-hoc queries, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The size of the body of work: source lines, commits, languages, systems, stories, ideas, tools, patent applications.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It lists content categories but does not state whether the tool is read-only, what it returns, or how the data is aggregated, leaving the agent to infer basic behavior.
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 followed by a compact list of categories, with no filler. Its brevity is appropriate, though the opening phrase is not framed as an action.
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 and no annotations, the description must explain what the tool returns and in what form. It names categories of scale but does not indicate whether the result is a number, a structured object, or a narrative summary, so the agent lacks enough context to invoke it confidently.
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 are no parameter semantics for the description to clarify. The baseline for a parameterless tool applies cleanly.
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 is a noun phrase listing dimensions of 'scale' rather than a verb+resource statement of what the tool does. It gives no clear action such as 'returns' or 'retrieves', so an agent cannot confidently distinguish it from list-oriented siblings like list_capabilities or list_systems.
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 explicit guidance on when to use this tool versus siblings such as list_systems, list_ideas, or search_portfolio. The only implied usage is that it relates to measuring body of work, but no selection criteria or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the systems, engineering stories, capabilities, ideas, technologies and patent applications. Returns ranked pages with their measured results and links.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It discloses that results are ranked pages with measured results and links, which is helpful, but says nothing about match semantics, ranking behavior, result limits, or whether the operation is read-only.
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, front-loaded with the search scope followed by return behavior. No filler, though the enumerated resource list is slightly long and unstructured.
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 3-parameter search tool with zero schema coverage, no annotations, and no output schema, the description is incomplete. It does not explain the kind values fully, the query semantics, the limit behavior, or how this differs from the sibling list_* tools.
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 0%, so the description must compensate for three undocumented parameters. It partially maps to the kind enum by naming resource types, but omits 'patent-family' and 'tool-group' entirely and gives no meaning for query or limit.
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 (Search) and enumerates the resource types it covers: systems, engineering stories, capabilities, ideas, technologies, patent applications. This clearly distinguishes it from a generic tool, but it never explicitly positions itself against the numerous list_* siblings.
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 on when to use this search tool versus list_systems, list_capabilities, list_ideas, and the other list_* siblings. The description implies a query-driven lookup but gives no exclusions, prerequisites, or alternative routes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who this is: name, the name used on patent filings, role, links and how to make contact.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and no output schema, so the description carries the full burden. It does disclose the kind of data returned (identity fields and contact pointers), which is the main behavioral trait for a zero-param read tool, but says nothing about whether the identity is fixed, whose identity it is, or how it relates to the other list_* tools.
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 short sentence with no waste. The 'Who this is:' lead is slightly awkward but front-loads the subject immediately.
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 trivial zero-param tool with no output schema, listing the returned fields is roughly the minimum needed. The gap is that it doesn't situate the tool among its many siblings, so completeness against the broader toolset is only adequate.
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?
Zero parameters, so baseline 4 applies. The description adds no parameter noise, which 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 clarifies that 'who' returns identity information — name, patent-filing name, role, links, contact — which the bare name 'who' does not convey. But the phrasing is a field list rather than a verb+resource statement, and it doesn't distinguish it from the sibling 'contact' tool, which plausibly covers the same contact information.
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 indication of when to call this versus 'contact', 'match_role', or 'get_page'. An agent seeing both 'who' and 'contact' has no basis in the description for choosing between them.
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.
contactget_pagelist_capabilitieslist_ideaslist_patent_applicationslist_systemslist_technologiesmatch_rolescalesearch_portfoliowhoSearch, read, and traverse 3,800+ posts on AI, energy, policy, games, and investing as a graph.
Search for AI agents. Closes the LLM-cutoff gap: CVEs, papers, frontier AI, prediction markets.
Query core AI knowledge, essays, executable Labs, Homeric data and epistemic claims.
Company brain for AI agents — temporal knowledge graph search, exploration, and durable memory.
Add one secure layer between your agents and this server.
