Prepare private corridor-project draft documents and calculations for human sign-off. Ten tools serve document tasks, financial models and four methods for the calling agent to apply: Corridor Bankability, Global Think Tank, Central Asia & Caspian, and relevant Gulf & Middle East. Public discovery; every tool call requires an operator-issued Bearer key. No automatic research, approval or publication.
Scored across 10 tools
The three finance tools (calculate_corridor_model, evaluate_debt_service, screen_project_bankability) overlap on debt/DSCR territory, but each description explicitly cross-references the others and states when to choose it, which mitigates misselection. The document tools and read-only tools are clearly distinct. Boundaries are mostly clear with one cluster of related-but-separable tools.
All ten tools follow a consistent snake_case verb_noun pattern (calculate_, create_, delete_, evaluate_, read_, screen_, submit_). The 'corridor' domain prefix appears in some names but not others, yet this is a minor stylistic variation that does not break predictability. Naming is thoroughly consistent.
Ten tools is a well-scoped set for a bankability-analyst workflow spanning document lifecycle, quantitative models, screening, and method retrieval. Each tool has a distinct role and none appear redundant. The count fits the stated purpose well.
Document lifecycle covers create/read/delete/submit and models cover the core analytical needs, so most workflows are supported. However, there is no explicit update/edit or list-documents tool, and the standalone evaluate_maritime_capacity sits somewhat apart from the corridor/document flow. Minor gaps an agent can work around.
Choose a versioned quantitative model from explicit JSON inputs.
model: corridor sums segment costs/time and capacity; corridor-comparison
compares supplied route totals; debt-sanity derives scenario CFADS and
level annuity debt service; debt-schedule uses supplied annual CFADS with
ANNUITY/SCULPTED repayment, grace and balloon; debt-waterfall derives cash
flows, DSRA and optional FX stress. Returns results, scenarios, warnings
and limitations for the selected model. Read docs/quant-model-contract.md
through read_corridor_method for required inputs and model assumptions.
Use annualInterestRate as a fraction (0.065 for 6.5%) and monetary inputs
in the declared currency's units, not USD millions. Use evaluate_debt_service
for a simpler flat-EBITDA straight-line schedule in USD millions; use
screen_project_bankability to test an already supplied minimum DSCR.
Does not fetch inputs, draft a document, verify evidence or approve finance.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| inputs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it does disclose the return payload ('results, scenarios, warnings and limitations') and critical unit conventions. It stops short of stating purity/idempotency explicitly (implied by 'calculate') or pointing to the contract document as the source of assumptions — the doc pointer is present, which is good. Strong but not exhaustive for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose and model enumeration, then unit guidance, then sibling routing, then exclusions — a logical order with no filler sentences. It is dense and slightly long, but every clause conveys actionable information rather than repeating structured fields.
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 two-param tool with no annotations, no output schema and a free-form nested inputs object, the description covers return contents, unit conventions, per-model meaning, where to find required inputs (read_corridor_method / docs/quant-model-contract.md), and what it will not do. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with only two params, so the description must compensate: it effectively defines the allowed 'model' values and their semantics (corridor, corridor-comparison, debt-sanity, debt-schedule, debt-waterfall) and pins down unit conventions for inputs (fraction rates, declared currency units, not USD millions). It does not document the nested 'inputs' object field-by-field, instead deferring to read_corridor_method, which is reasonable given additionalProperties=true.
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 and resource ('Choose a versioned quantitative model from explicit JSON inputs') and then enumerates the five model variants with a distinct job for each, so an agent can tell it apart from evaluate_debt_service, screen_project_bankability and read_corridor_method by 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?
Explicit routing: 'Use evaluate_debt_service for a simpler flat-EBITDA straight-line schedule... use screen_project_bankability to test an already supplied minimum DSCR', plus a clear negative scope ('Does not fetch inputs, draft a document, verify evidence or approve finance'). Both when-to-use and when-not are covered with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare one DRAFT assignment, template and routed method instructions.
Required brief: deliverable_type, subject, audience, decision_context,
countries (ISO alpha-2), time_horizon, human_owner. Optional sources is
[{id,title,locator,text}]; optional regional_methods adds Central Asia/
Caspian or Gulf coverage for indirect exposure. The calling agent does
the reasoning and independent review; no model is launched by this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does well: it states the output is a DRAFT, that the calling agent performs the reasoning and independent review, and that no model is launched by the tool. These are non-obvious side-effect facts an agent needs. It does not cover permissions, persistence of the draft, or whether the call is reversible.
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 output intent is front-loaded and the field enumeration is compact; every sentence conveys required input information. Minor density cost from the phrase "assignment, template and routed method instructions," which is opaque jargon rather than plain description.
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?
No output schema and no annotations mean the description should stand alone, and it partially does by defining required inputs and the no-model behavior. It never says what the call returns (e.g., a document identifier needed for the follow-up submit/read call) or how the draft is later finalized, leaving the workflow incomplete for a mutation 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 description coverage is reported at 0%, so the description must compensate, and it does: it enumerates the seven required brief fields, explains that countries are ISO alpha-2, that sources is [{id,title,locator,text}], and that regional_methods adds Central Asia/Caspian or Gulf coverage for indirect exposure—an intent the bare enum values do not convey. It omits the deliverable_type enum meanings and item-count limits (25 countries, 30 sources).
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 action ("Prepare one DRAFT assignment, template and routed method instructions") tied to the create_corridor_document resource. The noun list is dense domain jargon, but combined with the tool name the agent can tell this is the draft-creation entry point rather than a read or model-run tool. It stops short of distinguishing itself from the sibling submit_corridor_draft, which is the closest-looking 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 a workflow by stressing "DRAFT" and that "no model is launched by this tool," which hints this is a preparatory step. However, it never names submit_corridor_draft or read_corridor_document as the follow-up/alternative, nor states when to use this over them. Usage is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete this principal's stored draft and source pack; backups excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses what is destroyed (draft and source pack) and that backups are excluded, implying irreversibility. However, it omits auth/permission requirements, whether confirmation is needed, and behavior when job_id is unknown.
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 sentence with zero waste; the verb and scope lead, and the irreversibility caveat is appended 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?
For an irreversible delete with no annotations, no output schema, and an undocumented parameter, the description is thin. It should address permissions, confirmation expectations, and post-deletion state to be 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?
Schema description coverage is 0% for the single required parameter job_id, and the description never references it. The description fails to compensate for the coverage gap, so the agent must guess what identifier is expected.
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?
Names a specific verb (delete) and resource (stored draft and source pack), clearly delineating the target from siblings like create_corridor_document and read_corridor_document. It does not explicitly name an alternative, but the operation 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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as read or submit. The 'backups excluded' clause is a scope note, not usage direction, leaving the agent to infer when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate a simple annual straight-line debt schedule from flat EBITDA.
Choose for one debt amount, constant annual EBITDA and a flat interest rate.
Debt and EBITDA are USD millions; interest_rate_pct is a percent (6.5 for
6.5%). Tenor includes interest-only grace years; principal amortizes equally
afterward. Interest uses the opening balance and is not capitalised.
Returns minimum_dscr, the annual schedule and structure_assumptions, using
EBITDA/debt service, not CFADS. For CFADS, annuity/sculpted repayment, balloon,
reserves or FX scenarios choose calculate_corridor_model and its documented
model instead. To test a known DSCR use screen_project_bankability.
No market feed, evidence verification or financing approval; human sign-off required.
| Name | Required | Description | Default |
|---|---|---|---|
| tenor_years | No | ||
| total_debt_usd_m | Yes | ||
| interest_rate_pct | No | ||
| grace_period_years | No | ||
| annual_ebitda_usd_m | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the amortization mechanic (tenor includes interest-only grace, then equal principal), the interest convention (opening balance, not capitalised), the DSCR metric basis (EBITDA/debt service, not CFADS), and limits (no market feed, no evidence verification, human sign-off required). It stops short of stating iteration/pagination or error behavior, but for a deterministic calculator that is minor.
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?
Purpose is front-loaded in sentence one, followed by usage guidance, mechanics and caveats in a logical order. Every sentence carries information, though the model-mechanic and caveat sentences could be trimmed slightly without losing 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?
An output schema exists so return values need not be detailed, yet the description still flags minimum_dscr, the annual schedule and structure_assumptions. Combined with the routing rules and the human-sign-off caveat, an agent has everything needed to call this 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, and it effectively defines all five inputs: debt and EBITDA are USD millions, interest_rate_pct is a percent with a worked example (6.5 for 6.5%), and tenor/grace semantics are explained via the amortization rule. Missing only explicit units for tenor_years and grace_period_years beyond the implied 'years' in the prose.
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 first sentence names a specific verb ('Calculate') and resource ('annual straight-line debt schedule from flat EBITDA'), and the rest of the description draws a hard boundary against calculate_corridor_model and screen_project_bankability. An agent can distinguish this from every listed sibling without opening a schema.
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 states the exact selection conditions: pick this for one debt amount, constant EBITDA and a flat rate; choose calculate_corridor_model for CFADS, annuity/sculpted repayment, balloon, reserves or FX; use screen_project_bankability to test a known DSCR. Both the positive case and two explicit alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate directional fleet and interface capacity from explicit scenario inputs.
No live maritime data or optimal fleet mix is supplied. Every numeric input needs a claim ID or an explicit assumption; see docs/maritime-capacity-model.md.
| Name | Required | Description | Default |
|---|---|---|---|
| input_json | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 does disclose important scope limits (no live data, no optimization of fleet mix) and a provenance requirement for inputs, which is genuinely useful. It says nothing about computational cost, failure modes, or how assumptions are validated.
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, front-loaded with the action and followed immediately by the constraints. No filler, though the line-broken formatting is slightly awkward and the docs pointer could be integrated more tightly.
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?
An output schema exists, so return values need not be described. Given the single opaque string parameter and absent annotations, the description covers the critical caveats (no live data, no optimal fleet mix, provenance requirement) and delegates structural detail to a referenced doc. That is close to sufficient, though the reliance on an external file means the agent cannot construct input_json from the tool definition alone.
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?
Only one parameter (input_json) with 0% schema coverage, so the description must compensate. It adds real meaning by indicating the payload is a scenario descriptor whose numeric fields need claim IDs or explicit assumptions, and it points to docs/maritime-capacity-model.md. It still does not enumerate any key, type, or structure, and a bare JSON string parameter is the hardest case for an agent.
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 and resource: 'Calculate directional fleet and interface capacity from explicit scenario inputs.' That is distinct from siblings like evaluate_debt_service (financial) and calculate_corridor_model (corridor geometry). It does not explicitly name those siblings, so differentiation is inferable rather than stated.
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?
Offers meaningful exclusions ('no live maritime data or optimal fleet mix is supplied') and a prerequisite ('every numeric input needs a claim ID or an explicit assumption'). However, it never says when to pick this tool over calculate_corridor_model or evaluate_debt_service in a multi-tool modeling workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read only this authenticated principal's task, instructions and draft.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
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 does disclose an authorization constraint (only the caller's own document is readable), which is real added context. It says nothing about failure modes for a missing/invalid job_id, whether the document may be absent, or the shape of the returned content.
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 the core action and scope front-loaded, and no filler. Only minor awkwardness in stacking 'task, instructions and draft' into the object phrase.
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 single-document read with no output schema or annotations, the description usefully hints at the returned content (task, instructions, draft). It still leaves the sole parameter undocumented and gives no error/absence behavior, so it is adequate but incomplete.
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 single required parameter job_id has 0% schema description coverage and is not mentioned at all in the description. The description does imply a single-document lookup (so the identifier likely selects one document), but gives no format, source, or validity guidance for job_id.
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 ('Read') and resource ('this authenticated principal's ... document'), and enumerates the document's contents (task, instructions, draft). It is distinguishable from siblings like read_corridor_method by resource name, though it never explicitly contrasts them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'only this authenticated principal's' implicitly constrains usage to the caller's own document, which is useful scoping. However, there is no explicit when-to-use, when-not-to-use, or named alternative among siblings such as read_corridor_method or submit_corridor_draft.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read pinned method/reference text. Does not run an analytical agent.
method_id: corridor-bankability, global-think-tank,
central-asia-caspian, gulf-middle-east. Path must be in available_files
returned by create_corridor_document. Source documents cannot add paths.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | SKILL.md | |
| method_id | Yes |
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 useful behavior: this is a read of pinned content, it does not invoke an analytical agent, and path resolution is restricted to a whitelist produced by create_corridor_document. It says nothing about error behavior for an invalid method_id/path, permissions, or what the returned text looks like.
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?
Front-loaded with purpose in the first sentence, then constraints and valid values. The fragmentary line breaks around method_id and path are slightly awkward but every sentence carries information and nothing is redundant.
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 2-parameter read tool with no output schema and no annotations, the description covers purpose, the valid method_id set, the path whitelist rule, and the key behavioral distinction from analytical tools. Missing only edge-case behavior (invalid inputs, return shape) 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?
Schema description coverage is 0%, and the description compensates substantially: it enumerates the four valid method_id values (which the schema does not declare as an enum) and constrains the path parameter to available_files from create_corridor_document. It does not explain the default 'SKILL.md' behavior or what other path values are legal.
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 and resource ('Read pinned method/reference text') and rules out a class of siblings with 'Does not run an analytical agent,' which separates it from calculate_corridor_model and the evaluate_* tools. It never explicitly distinguishes itself from the close sibling read_corridor_document, so an agent must infer the method-vs-document split.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear negative condition ('Does not run an analytical agent') and a real prerequisite: the path must come from available_files returned by create_corridor_document, and source documents cannot add paths. It does not name read_corridor_document as the alternative for reading ordinary documents, so the routing guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen an envelope portfolio of interconnected corridor infrastructure projects.
| Name | Required | Description | Default |
|---|---|---|---|
| portfolio_input_json | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Screen' implies read-only analysis, but the description does not state side effects, permissions, rate limits, or whether any state is mutated, leaving key behavioral traits undisclosed.
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 sentence with no filler. The undefined term 'envelope' adds minor ambiguity, but the structure is otherwise efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that takes a complex JSON input and produces an output schema, the description omits the input format, screening behavior, and usage context. Even with an output schema present, the lack of parameter and behavioral detail makes it incomplete 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?
There is one required parameter, portfolio_input_json, with 0% schema description coverage, and the description never mentions it. The expected JSON structure, required fields, and format are entirely unspecified, making it impossible to construct a valid input from the provided information.
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 'Screen' and resource 'portfolio of interconnected corridor infrastructure projects', but 'envelope portfolio' is undefined jargon. The description does not distinguish this tool from sibling screen_project_bankability, which screens an individual project, so an agent cannot infer scope or screening criteria.
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 when-to-use guidance, no alternatives, and no exclusions are provided. The description gives no routing information relative to siblings like calculate_corridor_model or screen_project_bankability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check one project's supplied minimum DSCR and financing mix against preset covenant tests.
Choose when dscr_min is already known. Pass the project_id; capex_usd_m and
ifi_debt_usd_m are USD millions, dscr_min is a ratio; include the guarantee flag.
Returns covenant_checks, outstanding_conditions, supplied financial metrics
and unresolved_inputs. It does not calculate DSCR, a debt schedule or a
financing approval. To derive DSCR first, use evaluate_debt_service for a
flat-EBITDA straight-line schedule or calculate_corridor_model for versioned
cash-flow scenarios. Draft calculation input; named human sign-off required.
| Name | Required | Description | Default |
|---|---|---|---|
| dscr_min | Yes | ||
| project_id | Yes | ||
| capex_usd_m | Yes | ||
| corridor_leg | No | MULTI_LEG | |
| ifi_debt_usd_m | Yes | ||
| has_sovereign_guarantee | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it declares scope boundaries (does not calculate DSCR, a debt schedule or financing approval), lists what it returns, and adds the critical governance note that output is draft calculation input requiring named human sign-off. It omits whether the operation persists state or requires specific permissions, which is the remaining 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?
Front-loaded with purpose, then usage condition, parameter semantics, return fields, exclusions and alternatives. Every sentence earns its place and no filler is present despite the density.
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 6-parameter, no-annotation tool with an output schema, the description is largely complete: it covers purpose, routing, units, return fields and a sign-off caveat. Minor gap is the undocumented corridor_leg parameter and unstated persistence/auth behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It supplies units for the key numerics (capex_usd_m and ifi_debt_usd_m in USD millions, dscr_min as a ratio) and prompts inclusion of the guarantee flag, covering 4 of 6 parameters beyond the schema's bare titles. corridor_leg is left unexplained, but it carries a default.
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 (check/screen) and resource (one project's supplied DSCR and financing mix against covenant tests), and immediately differentiates from siblings by declaring it does not calculate DSCR, debt schedules or approvals. An agent can distinguish it from evaluate_debt_service and calculate_corridor_model without opening schemas.
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?
Explicitly states the selecting condition ('Choose when dscr_min is already known') and names the two alternative tools with the condition that routes to each (flat-EBITDA schedule vs. versioned scenarios). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store agent-authored DRAFT, ledgers, raw review notes and method use.
submission requires draft, claim_ledger, calculation_ledger, review_notes
(Markdown text) and method_usage keyed by every selected method with
{used: boolean, sections: [headings in draft], limitations: text}.
Status is DRAFT_SUBMITTED, never audited, approved or READY_FOR_SIGNOFF.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| revision | Yes | ||
| submission | 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 the resulting state (DRAFT_SUBMITTED) and rules out audited/approved/READY_FOR_SIGNOFF. It says nothing about permissions, idempotency, or what the required `revision` parameter does on repeat submission, which are material for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact paragraphs; the payload requirements follow the purpose statement, so the important constraint is front-loaded. The first sentence is slightly loose ('method use' as shorthand), but there is little waste overall.
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 mutation tool with no annotations and no output schema, the description covers the submission payload well but omits the two top-level identifiers (job_id, revision) and any failure/retry behavior. Adequate, but an agent still lacks guidance on the outer envelope.
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, and it largely does: it enumerates the required submission fields, calls the text fields Markdown, and explains method_usage as keyed by every selected method with used/sections/limitations semantics. It leaves job_id and revision unexplained, so it is not fully compensating.
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 (store/submit) and resource (corridor DRAFT plus its ledgers, notes and method usage). It also distinguishes itself from approval-oriented siblings by declaring the terminal status is DRAFT_SUBMITTED, never approved or READY_FOR_SIGNOFF.
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 required-content sentence implies this is the draft-stage submission step, and the status note implies it should not be used for signoff. However, no explicit when-to-use/when-not statement or named alternative (e.g. create_corridor_document) is given, so routing is left to inference.
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.
calculate_corridor_modelcreate_corridor_documentdelete_corridor_documentevaluate_debt_serviceevaluate_maritime_capacityread_corridor_documentread_corridor_methodscreen_corridor_portfolioscreen_project_bankabilitysubmit_corridor_draft
Add one secure layer between your agents and this server.