Complete regulated intake work before human review. Klarefi gathers context, reads documents, resolves cited facts, runs verification, and prepares auditable case files.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.7/5 across 20 of 20 tools scored. Lowest: 2.4/5.
Most tools have clearly distinct purposes, such as answer_fields vs answer_question or the various intake actions. However, get_case, get_case_package, and get_case_workspace all retrieve case-related information and could be confused, and create_connector vs create_connector_from_openapi are similar. Overall, descriptions help separate them.
All tool names follow a consistent verb_noun pattern in snake_case, such as create_, get_, list_, save_, submit_, upload_, and wait_. The naming is highly predictable and uniform across the set.
With 20 tools, the server is slightly above the typical well-scoped range of 3-15 but still reasonable for a case-management platform covering intake, review, connectors, and workflows. Each tool serves a distinct function, though some consolidation could be possible.
The tool surface covers the main intake, case review, and connector lifecycle well. Minor gaps exist: there is no explicit tool to complete or reopen a case, and workflows cannot be published or activated after saving a draft. These are workable but notable omissions.
answer_fieldsAnswer intake fieldsBAnswer structured requested facts by fact_id. Values must be strings; yes_no fields take "yes" or "no", and date fields use YYYY-MM-DD.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Signed hosted intake URL. Include it in every call to the hosted MCP endpoint. | |
| fields | Yes | String values keyed by fact_id. | |
| task_id | No | ||
| session_id | No | ||
| access_token | No | Applicant access token. Use it with session_id instead of url. | |
| api_base_url | No | Optional Klarefi deployment URL for local stdio use. The hosted MCP endpoint does not accept this override. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, destructive action. The description adds value by specifying input format constraints (strings, yes_no, date format) but does not disclose other behavioral traits like overwriting behavior, auth requirements, or side effects beyond what annotations provide.
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 states the purpose and then essential format rules. Every word contributes, with no padding or repetition.
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?
Despite annotations and partial schema coverage, the description lacks workflow context: it does not explain how fact_ids are obtained, how url/access_token/session_id relate, or what happens after submission. For a destructive tool with six parameters, 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?
Schema coverage is 67%, with task_id and session_id undocumented. The description compensates by explaining value formats (yes_no, date) not present in the schema, but it does not clarify the undocumented parameters or interactions, so it doesn't reach a 5.
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 ('Answer') and resource ('structured requested facts by fact_id'), making the core purpose clear. It does not explicitly distinguish itself from sibling tools like answer_question, so it misses the top score for sibling differentiation.
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 no guidance on when to use this tool versus alternatives such as answer_question or submit_intake. There is an implied use case (when you have fact_ids to answer) but no explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
answer_questionAnswer intake questionAAnswer the active applicant question with free text, optionally targeting a task_id.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Signed hosted intake URL. Include it in every call to the hosted MCP endpoint. | |
| text | Yes | ||
| task_id | No | ||
| session_id | No | ||
| access_token | No | Applicant access token. Use it with session_id instead of url. | |
| api_base_url | No | Optional Klarefi deployment URL for local stdio use. The hosted MCP endpoint does not accept this override. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation nature is known. The description adds minimal behavioral context: it is an answer action, and task_id can be targeted. It does not mention reversibility, required auth context, or consequences beyond what annotations imply. With annotations covering the safety profile, a 3 is appropriate.
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 sentence of 12 words, front-loaded with the verb and object. There is zero redundancy; every word adds value. It is efficient and immediately comprehensible.
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 6 parameters, no output schema, and destructive behavior, the description is too terse to be complete. It does not explain what 'active' means, how the answer is delivered, what the return value is, or how authentication flows between url/access_token/session_id. The lack of any guidance on prerequisites or effects makes this below the minimum viable for a tool of this 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 coverage is 50%, and the description adds meaning to 'task_id' by noting it is an optional targeting mechanism. However, it does not clarify 'text' (the only required param) or 'session_id' interactions with 'url' and 'access_token'. The schema already explains auth tokens, but description fails to compensate for the under-documented parameters. Partial addition, so score 3.
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 action ('Answer'), the target resource ('active applicant question'), and the method ('free text'). It distinguishes from sibling 'answer_fields' by specifying free text, and the optional task_id adds scope. This is specific and unambiguous.
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 'active applicant question' implies the tool should be used when there is an active question to answer, and 'optionally targeting a task_id' hints at usage context. However, it does not explicitly contrast with alternatives like answer_fields, nor does it provide exclusions or prerequisites. Usage is implied but not fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_connectorCreate or update connectorACreate or update a Klarefi verification connector manifest. The connector is active as soon as this returns — there is no draft/review step, so review its functions before routing live traffic.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While destructiveHint=true is already annotated, the description adds meaningful behavioral context: the connector is active as soon as the call returns and there is no draft/review step. It also warns about the irreversibility of routing live traffic, which goes beyond the raw 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?
The description is two sentences, front-loads the purpose, and every clause adds value. It wastes no words and communicates the essential behavior and caution efficiently.
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?
The description is clear about the tool's core behavior and the critical consequence of immediate activation, which is especially important given destructiveHint=true. It lacks parameter-level details and does not describe potential return values, but the absence of an output schema and the schema's high coverage partially mitigate this. For a mutating tool with a warning, the description is sufficiently complete.
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 description does not explain any parameter semantics; it only mentions 'functions' in the context of review. However, schema description coverage is 100%, so the baseline is 3, and the description does not add significant value beyond the schema's parameter names.
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 specific verbs 'Create or update' with a clear resource ('Klarefi verification connector manifest'). It also differentiates from the sibling 'create_connector_from_openapi' by focusing on direct manifest creation/update, and adds unique context about immediate activation.
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 provides clear context that the connector becomes active immediately and there is no draft/review step, advising the user to review functions before routing live traffic. It does not explicitly name alternatives or state when not to use this tool, but the caution clarifies a key usage consideration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_connector_from_openapiImport connector from OpenAPIAImport a public OpenAPI JSON URL as a Klarefi verification connector. JSON specs only (convert YAML first). The connector goes live immediately — review its functions before routing live traffic.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | ||
| base_url | No | ||
| openapi_url | Yes | ||
| connector_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral detail beyond annotations by stating the connector 'goes live immediately' and advising review before routing traffic. This supplements the destructiveHint and openWorldHint annotations without contradicting them.
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 three concise sentences, front-loaded with the core purpose and followed by essential constraints and caveats. Every sentence earns its place with no redundant content.
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?
The description covers key operational expectations (JSON-only, immediate activation) but omits parameter semantics and return behavior. With no output schema and 0% schema coverage, the description should provide more detail to fully guide an agent.
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%, and the description does not explain the meaning or expected values for connector_key, base_url, or label. It only mentions 'public OpenAPI JSON URL', which maps loosely to openapi_url, leaving required parameters under-documented.
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 'Import a public OpenAPI JSON URL as a Klarefi verification connector', naming the specific verb, resource, and format. This distinguishes it from sibling tools like 'create_connector', which likely handles manual connector creation.
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 provides clear context: the tool is for importing public OpenAPI JSON URLs, and explicitly notes JSON-only specs with guidance to convert YAML first. It does not explicitly name alternatives or exclusion cases, but the context is sufficient for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_intake_sessionCreate intake sessionCInspectCreate a hosted Klarefi intake session.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | ||
| prefill | No | Prefill payload passed through to the session; schema owned by the prefill feature | |
| ttl_hours | No | ||
| return_url | No | ||
| case_type_id | Yes | ||
| external_case_id | No | ||
| external_customer_id | No | ||
| external_applicant_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and provide no safety or behavioral hints. The description only restates that it creates a session, adding no information about side effects, required case_type_id, return value, or how the hosted session is accessed afterward. This is minimal beyond the tool name.
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 concise sentence with no wasted words, but it is not appropriately sized for a tool with 8 parameters and nested objects. It is under-specified rather than merely concise, so a medium score is appropriate.
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?
The description provides no output schema, no parameter details, no usage guidance, and no behavioral context. For a tool with this complexity, the description is severely inadequate and leaves the agent without essential information 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 description coverage is only 13% (only 'prefill' has a description), and the tool description mentions no parameters at all. With 8 parameters, including a required case_type_id, the description fails to compensate for the missing schema documentation, leaving most parameters unexplained.
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 action ('Create') and the resource ('a hosted Klarefi intake session'), which distinguishes it from sibling tools like submit_intake or open_intake. However, it doesn't explicitly differentiate from alternatives, so it's clear but not fully unique.
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 provides no guidance on when to use this tool versus alternatives such as open_intake, submit_intake, or save_intake_draft. No context, prerequisites, 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.
delete_connectorDelete connectorADelete a configured Klarefi connector by key.
| Name | Required | Description | Default |
|---|---|---|---|
| connector_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description aligns by stating 'Delete'. However, it does not disclose potential side effects such as irreversibility, cascade effects on dependent data, or permission requirements. It adds minimal context ('configured' and 'by key') but relies heavily on the annotation flag.
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, succinct sentence that gets straight to the point. It is front-loaded with the verb and contains no unnecessary 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 delete operation with one parameter and no output schema, the description is spartan. It does not mention what happens after a successful deletion, any error conditions, or whether the operation is permanent. While annotations cover the destructive nature, the description lacks operational context for the agent to confidently invoke 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 schema has 0% coverage, so the description must compensate. The phrase 'by key' echoes the parameter name 'connector_key' without adding format details, how to obtain the key, or its expected values. This provides little value beyond the schema itself.
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's function: deleting a configured Klarefi connector by key. The verb 'Delete' is specific, and the resource is well-defined, distinguishing it from sibling tools like create_connector or get_case.
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 for removing connectors but does not explicitly mention when to use it over alternatives or any preconditions. It is unclear whether deletion is only for connectors created by create_connector, or if there are restrictions. Thus, it provides only implied usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_caseGet caseBRetrieve a Klarefi case and resolved facts.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, establishing the safety profile. The description adds that the tool returns 'resolved facts,' which is useful output context, but it doesn't elaborate on what resolved facts are or any other behavioral characteristics.
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, well-structured sentence that uses every word effectively. It's immediate and front-loaded with the 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?
The description tells the agent what it returns (case and resolved facts) but omits detail about the structure of those facts and provides no usage context relative to sibling tools. The annotations help, but the lack of an output schema or alternative guidance leaves gaps.
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 only one parameter (case_id) and zero schema description coverage, the description implicitly indicates that the parameter is a Klarefi case identifier by stating 'Retrieve a Klarefi case.' This provides some meaning, but the parameter's format is left entirely to inference.
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 a specific verb ('Retrieve') and resource ('Klarefi case and resolved facts'), which distinguishes it from sibling tools like get_case_package by mentioning resolved facts. However, it doesn't explicitly name alternatives, so it's clear but not fully differentiated.
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 provided about when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparisons to sibling tools like get_case_workspace or get_review_command.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_packageGet case packageAGet the cited case_package.v1 artifact and a signed read-only case-file URL.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful context by specifying the returned URL is signed and read-only, which clarifies the nature of the output. This goes beyond annotation data and provides value without contradiction.
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 directly states the action and outputs without any redundant or unnecessary information.
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 tool's simplicity (one parameter, no output schema), the description adequately names both return elements (artifact and signed URL) and conveys the overall purpose. It lacks edge-case or caveat information, but annotations cover safety aspects, making it fairly complete.
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 has a single parameter 'case_id' as a required string with no description, and the tool description does not elaborate on its meaning or format. With 0% schema description coverage, the description fails to compensate for the lack of parameter 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?
The description clearly states the tool's function with a specific verb ('Get') and resource ('case_package.v1 artifact'), also mentioning an additional output ('signed read-only case-file URL'). This distinguishes it well from sibling tools like get_case and get_case_workspace.
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 purpose implies usage (retrieve the cited case package), but the description does not explicitly state when to use this tool over alternatives or mention any exclusions. There is no comparison with sibling tools, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_workspaceGet case workspaceBInspect a case workspace with facts, cited evidence, blockers, ownership, and timeline. This does not mutate the case.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description repeats that it does not mutate, adding no new behavioral context beyond annotations. No additional traits like auth requirements or pagination are disclosed.
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 short sentences, front-loaded with the action and scope. No 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 read-only tool with one parameter, the description lists the contents of the workspace and its safe nature. However, it doesn't clarify the meaning of case_id or differentiate from overlapping siblings, so it's not fully complete.
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 one required parameter (case_id) with no description. The description does not mention the parameter or explain its format, leaving the agent to infer from the name. With 0% schema coverage, this is a gap.
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 ('Inspect'), identifies the resource ('case workspace'), and enumerates its contents (facts, cited evidence, blockers, ownership, timeline). This distinguishes it from sibling tools like get_case by scope, though it doesn't explicitly name an alternative.
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 for inspecting a workspace and explicitly states it does not mutate, but provides no guidance on when to prefer this over get_case or get_case_package, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_intake_stateGet intake stateAGet the current applicant intake state. Pass url, or session_id with access_token, on the hosted MCP endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Signed hosted intake URL. Include it in every call to the hosted MCP endpoint. | |
| session_id | No | ||
| access_token | No | Applicant access token. Use it with session_id instead of url. | |
| api_base_url | No | Optional Klarefi deployment URL for local stdio use. The hosted MCP endpoint does not accept this override. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds context about authentication methods and the hosted/local endpoint distinction, which is valuable beyond the structured annotations. No contradiction exists.
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 sentences, front-loaded with the main purpose followed by essential usage details. Every word earns its place, with no redundancy.
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 absence of an output schema and the tool's simplicity, the description provides enough operational context: how to specify the target intake and the endpoint mode. It doesn't describe the return structure, but that's not required without an output schema and the read-only annotations cover side effects.
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 75% (three of four parameters have descriptions). The description clarifies that session_id must be used with access_token, and explains api_base_url's purpose for local stdio use, adding meaning not fully captured in the schema. However, session_id itself remains undocumented.
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 ('Get') and resource ('current applicant intake state'), making the tool's core function clear. It doesn't explicitly differentiate from siblings like 'open_intake' or 'get_case', but the resource and state focus distinguish it sufficiently.
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 explains the two ways to call the tool (url or session_id with access_token) and notes the hosted MCP endpoint distinction from local stdio via api_base_url. However, it doesn't state when to prefer this tool over alternatives or mention any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_review_commandGet review commandBPoll the status and result of an intake-review command.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes | ||
| command_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that this tool polls for status and result, which suggests repeated calls are safe and expected. No additional behavioral details (e.g., polling intervals, error cases) are provided, but the annotation coverage lowers the burden.
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 sentence that is front-loaded with the primary action ('Poll') and the target ('status and result'). No filler or redundant phrasing; every word contributes meaning.
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 explain what the tool returns, but it only says 'status and result' without specifying possible statuses, result structure, or failure behavior. The tool also lacks context on how the two IDs relate. This is insufficient for an agent to fully anticipate the response.
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%, and the description does not explain case_id or command_id. While the parameter names are self-explanatory, the description offers no guidance on their relationship or expected format, failing to compensate for the lack of schema descriptions.
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 ('Poll') and clearly names the resource ('status and result of an intake-review command'). This distinguishes it from general case or state retrieval tools, though it does not explicitly name sibling alternatives.
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 use this tool versus alternatives like get_case, get_intake_state, or submit_case_review. The description implies a polling use case but provides no prerequisites, exclusions, or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_operator_queueList operator queueAList the bounded Klarefi operator queue for this API key's environment. Requires cases:review.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the annotations by disclosing a required permission ('cases:review') and scoping the queue to the API key's environment. It also notes the queue is 'bounded,' which is a behavioral characteristic not captured by the readOnly or idempotent hints. However, it does not elaborate on the exact bounds or return format.
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, well-structured sentence that directly states purpose, scope, and permission. It contains no redundant phrases and every word adds meaning, making it appropriately concise and easy to parse.
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 list tool, the description provides core operational details (what, where, permission) but does not explain what the queue contains or the return structure. Given the lack of an output schema, the agent may need more context to fully understand the tool's role in the broader workflow.
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 includes one parameter, 'limit,' but the description does not mention it or explain its purpose. With 0% schema description coverage, the description should compensate by defining the limit's effect on results, but it does not, leaving the agent to infer from the parameter name and constraints.
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 the specific verb 'List' and clearly identifies the resource as 'the bounded Klarefi operator queue for this API key's environment.' This distinguishes it from sibling tools like get_case or list_workflows, which operate on different resources or actions.
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 does not state when to use this tool versus alternatives, nor does it mention exclusions or conditions beyond the permission requirement 'Requires cases:review.' It provides no guidance on selecting this over other list tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_workflowsList workflowsAList versioned Form · Fact · Verify workflow declarations.
| 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 covered. The description adds useful context with 'versioned' and the 'Form · Fact · Verify' categorization, which goes beyond the annotations by describing the nature of the returned items.
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 with no filler or redundancy. Every word adds meaning, and it is appropriately sized for a tool of this 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?
Given the tool's low complexity (no parameters, no nested objects), the annotations cover safety, and the description states exactly what is listed. The absence of an output schema is compensated because the description implies the return of workflow declarations. The tool is simple enough that this description is fully complete.
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, so there is nothing to explain. Per rubric, a baseline of 4 is appropriate when no parameters exist. The description does not need to add parameter 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?
The description uses a specific verb ('List') and identifies the exact resource ('versioned Form · Fact · Verify workflow declarations'), clearly distinguishing it from sibling tools that operate on cases, connectors, or intakes. The purpose is unambiguous.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It merely states what the tool does without contextual cues, so an agent receives no help in deciding between this and other workflow-related tools like save_workflow_draft.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
open_intakeOpen intakeARead an applicant intake from a signed URL or from session_id plus access_token. No Klarefi API key is required. On the hosted MCP endpoint, include the same intake credential in each later intake tool call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Signed hosted intake URL. Include it in every call to the hosted MCP endpoint. | |
| session_id | No | ||
| access_token | No | Applicant access token. Use it with session_id instead of url. | |
| api_base_url | No | Optional Klarefi deployment URL for local stdio use. The hosted MCP endpoint does not accept this override. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond that: no API key is needed, and the hosted endpoint requires including the same intake credential in later intake calls. This enriches the safety profile with auth and state-handling details; no contradiction.
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?
Three short sentences, each carrying distinct information: the core read operation, the auth requirement, and the hosted endpoint credential practice. The description 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 read tool with no output schema, the description covers access modes, auth requirements, and endpoint-specific behavior, making it sufficient for selecting and invoking the tool. It could still explicitly mention return shape or differentiate itself from get_intake_state, but overall it is complete enough given the annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with useful descriptions for url, access_token, and api_base_url. The description compensates by explaining the relationship between session_id and access_token, repeating the no-API-key requirement, and adding hosted-vs-local override context. The undocumented session_id is partially clarified by the phrase 'session_id plus access_token'.
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 starts with a specific verb and resource: 'Read an applicant intake', and immediately clarifies the two access modes (signed URL or session_id plus access_token). This clearly distinguishes it from siblings like create_intake_session or submit_intake.
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 indicates when to use the tool (reading an intake) and gives important context: no Klarefi API key is required, and on the hosted endpoint the same intake credential should be included in later calls. It does not explicitly name alternative tools or exclusions, so a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_intake_draftSave intake draftASave applicant form draft fields without submitting. Field values must be strings or null.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Signed hosted intake URL. Include it in every call to the hosted MCP endpoint. | |
| fields | Yes | Draft field values keyed by field_id. | |
| session_id | No | ||
| access_token | No | Applicant access token. Use it with session_id instead of url. | |
| api_base_url | No | Optional Klarefi deployment URL for local stdio use. The hosted MCP endpoint does not accept this override. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the write behavior is known. The description adds useful context by clarifying that saving does not trigger submission, and it discloses a data-type requirement ('strings or null') that is not present in the schema. This goes beyond the annotations without contradicting them.
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 short sentences convey the core purpose and a critical constraint with no filler. Every word earns its place; the second sentence is a crisp, actionable requirement.
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 5-parameter tool with no output schema, the description covers the essential behavioral context (save, no submission) and a key parameter constraint. The auth methods are already documented in the schema, so the description is sufficiently complete for correct invocation, though it could note the distinction from submit_intake more explicitly.
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 80%, giving a baseline of 3. The description enriches the 'fields' parameter by specifying value types ('strings or null'), which is not stated in the schema. It does not discuss the alternative auth parameters (url vs session_id/access_token), but those are sufficiently described in 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 states the action ('Save') and the specific resource ('applicant form draft fields'), and adds the critical qualifier 'without submitting' that distinguishes it from submission tools. It also implicitly differentiates from the sibling save_workflow_draft by focusing on applicant forms.
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 'without submitting' implies a use case distinct from final submission, but it does not explicitly mention when to use this tool versus submit_intake or save_workflow_draft. There is no explicit alternative or exclusion, so guidance remains 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.
save_workflow_draftSave workflow draftAValidate and save a workflow declaration as a draft. This tool cannot publish or activate the workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| workflow | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is not read-only (readOnlyHint=false) and is destructive (destructiveHint=true). The description adds useful behavioral context: the tool validates the workflow before saving, and cannot publish or activate. This goes beyond the structured annotations, though it does not detail side effects like overwriting existing drafts.
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 sentences: the first states the core action, the second clarifies a key limitation. Every word is relevant, and it is optimally front-loaded with the purpose. No fluff or repetition.
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?
The tool is relatively simple (one parameter, no output schema), but the nested 'workflow' object is unspecified, and the description does not indicate what a valid workflow declaration looks like or what the tool returns. The description covers the main purpose and limitation, but for a validation-saving tool, more detail about the input structure would be expected for full 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?
The schema has one parameter 'workflow' with no description and additionalProperties true, so schema coverage is 0%. The description refers to it as a 'workflow declaration,' giving a minimal hint, but does not explain what fields or structure are expected. The description fails to compensate for the lack of schema documentation, leaving the parameter semantics largely unexplained.
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's purpose: 'Validate and save a workflow declaration as a draft.' The verb 'save' is specific, the resource is a 'workflow draft,' and it is distinguished from publishing or activation by explicitly saying it cannot do those. This differentiates it from other save tools like save_intake_draft.
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: this tool is for saving drafts and explicitly excludes publishing or activating. This helps the agent know when not to use it (when the goal is to publish). However, it does not name an alternative tool for publishing, so it receives a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_case_reviewSubmit case review commandBSubmit an auditable intake-review command. Allowed commands review or correct facts, request clarification, update evidence, or escalate. This tool cannot complete or reopen a case.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes | ||
| payload | Yes | ||
| trace_id | No | ||
| rationale | No | ||
| command_type | Yes | ||
| idempotency_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so the description does not need to restate mutability. It adds the context 'auditable' and lists allowed command types, which is useful. However, it does not disclose side effects, permission requirements, or what happens on execution, leaving some behavioral gaps.
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 sentences, front-loaded with the primary purpose, followed by allowable commands and a limitation. Every sentence earns its place with no redundant filler, making it highly concise and well-structured.
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 tool's complexity (6 parameters, nested payload, enum, no output schema, destructive hint), the description is too sparse. It does not explain the payload structure, idempotency key usage, or expected output, and it lacks guidance relative to siblings like get_review_command or submit_intake. Significant information is missing 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?
With 0% schema description coverage, the description must compensate for parameter meaning. It only adds value for command_type by enumerating allowed values, but leaves case_id, payload, trace_id, rationale, and idempotency_key unexplained. This is insufficient for a tool with six parameters and a nested object payload.
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's function: 'Submit an auditable intake-review command' with specific verbs and a resource. It further lists allowed command types (review/correct facts, clarify, update evidence, escalate), which adds scope. However, it does not explicitly name sibling tools for differentiation, though the negative constraint 'cannot complete or reopen a case' helps distinguish from submission tools.
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 provides explicit when-to-use context by enumerating allowed commands and disallowed operations ('cannot complete or reopen a case'). It does not name alternative tools, but the negative constraint clearly implies when not to use it, earning a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_intakeSubmit intakeASubmit the applicant intake. Returns submitted, blockers, and the fresh intake state.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Signed hosted intake URL. Include it in every call to the hosted MCP endpoint. | |
| session_id | No | ||
| access_token | No | Applicant access token. Use it with session_id instead of url. | |
| api_base_url | No | Optional Klarefi deployment URL for local stdio use. The hosted MCP endpoint does not accept this override. | |
| field_values | No | Optional final field values; each value must be string or null. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the annotations by disclosing the return structure ('submitted, blockers, and the fresh intake state'), which gives insight into potential validation outcomes. It does not contradict the destructiveHint=true annotation, and the description highlights non-obvious behavior (presence of blockers) that the annotations do not convey.
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 extremely concise, consisting of two short sentences. The first sentence states the action, and the second lists the return values. There is no redundant or vague phrasing, making it efficient and easily scannable.
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?
While the description covers the core purpose and return structure, it leaves gaps: no explanation of what 'blockers' are, how to interpret them, or any prerequisites for submission. With no output schema, the agent relies on the description for response semantics, and the term 'fresh intake state' is vague without 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 input schema already provides descriptions for 4 of 5 parameters (80% coverage), so the description does not need to repeat parameter details. The description itself adds no parameter-level meaning, but given the high schema coverage, a 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 states the tool's function with a specific verb and resource: 'Submit the applicant intake.' It distinguishes from sibling tools like open_intake and save_intake_draft by indicating a final submission action, and the mention of return values ('submitted, blockers, and the fresh intake state') reinforces the purpose.
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 when an intake is ready to be finalized, but it does not explicitly state when to use this tool over alternatives. No mention of exclusions or alternative tools like save_intake_draft is provided, leaving the decision to the agent's inference from the verb 'submit'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_documentUpload intake documentAInspectUpload a requested applicant document. Use content_base64 on the hosted MCP endpoint. Local stdio clients can use file_path. Inline content is limited to 5MB decoded; local files can be up to 25MB.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Signed hosted intake URL. Include it in every call to the hosted MCP endpoint. | |
| task_id | No | ||
| filename | No | Required with content_base64. Defaults to the basename of file_path. | |
| file_path | No | ||
| mime_type | No | ||
| session_id | No | ||
| access_token | No | Applicant access token. Use it with session_id instead of url. | |
| api_base_url | No | Optional Klarefi deployment URL for local stdio use. The hosted MCP endpoint does not accept this override. | |
| content_base64 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the tool is not read-only, not idempotent, and not destructive. The description adds useful behavioral details beyond the annotations: the two different upload mechanisms (content_base64 vs file_path) and payload size constraints (5MB decoded inline, 25MB local). It doesn't cover auth requirements or failure behavior, but the annotation baseline lowers that need.
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 three sentences, front-loaded with the purpose, and contains no filler. Each sentence adds necessary operational information about endpoint types and size limits.
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 tool has 9 parameters, no output schema, and minimal annotations, the description is not fully complete. It covers upload methods and limits but omits the access_token/session_id path visible in the schema, doesn't clarify required parameter combinations, and doesn't say what a successful upload returns. It is adequate for simple cases but insufficient for a complex tool.
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 only 44%, so the description must compensate. It does add meaning for content_base64 and file_path, plus size limits, but it does not explain key parameter relationships like the alternative access_token+session_id flow or the purpose of task_id and mime_type. This is partial compensation, leaving notable gaps.
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 'Upload a requested applicant document' — a specific verb with a clear resource and context. It is easily distinguished from sibling tools like create_intake_session or submit_intake, which handle other stages of the intake workflow.
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 explicit operational context: use content_base64 on the hosted MCP endpoint, use file_path for local stdio clients, and notes size limits. It does not explicitly name alternative tools or state when not to use this tool, but the guidance is clear enough for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wait_for_next_actionWait for next intake actionAPoll until the intake leaves processing or the timeout expires. If timed_out is true, call wait_for_next_action again.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Signed hosted intake URL. Include it in every call to the hosted MCP endpoint. | |
| session_id | No | ||
| access_token | No | Applicant access token. Use it with session_id instead of url. | |
| api_base_url | No | Optional Klarefi deployment URL for local stdio use. The hosted MCP endpoint does not accept this override. | |
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's additional value is the polling behavior and the fact that it may return early with timed_out=true, followed by a safe retry. This adds context beyond the structured annotations and is consistent with them.
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 sentences, front-loaded with the core purpose and followed by a brief retry instruction. Every word earns its place; no fluff or redundancy.
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 polling tool, the description covers the essential behavior (poll until state change or timeout) and the retry action on timeout. It does not explain the full return structure, but without an output schema and given the simplicity, this is sufficient. Minor gaps remain about auth parameter selection, but those are partially covered in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description references 'timeout expires,' which arguably maps to the timeout_seconds parameter, but it does not explain the undocumented session_id parameter or clarify the relationship between url, session_id, and access_token. With only 60% schema description coverage and no compensating detail in the description, parameter semantics are under-served.
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 polls until the intake leaves processing or timeout expires, which is a specific verb (poll) with a resource (intake) and termination condition. This distinguishes it from siblings like get_intake_state that likely return the current state without blocking.
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 a clear retry instruction for timeouts ('If timed_out is true, call wait_for_next_action again'), which is useful. However, it does not explicitly contrast with alternatives like get_intake_state or state when not to use this tool, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
