# Generate the first config.yml from a reviewed API contract

Attach your reviewed api-context.md and the tools, mapping, authentication, and quick-start documentation for the AGENTO version you use. This prompt can be used in a fresh conversation with any model.

Create one read-only AGENTO v2 tool for my real API using only the attached contract and AGENTO references.

Before writing YAML:
- Summarize the chosen endpoint and its successful outcome.
- Ask about any UNKNOWN affecting method, URL, required input types, or authentication. Do not guess.
- Trace every value from its owner to its HTTP destination.

Produce a complete minimal config.yml:
- version is the string "2"; tools contains one tool.
- Use a stable id, a specific tool.description, and a draft-07 JSON Schema in tool.input_schema.
- input_schema describes tool arguments; it does not automatically send them to the API.
- Copy request.method and request.url from the contract. Explicitly map path, query, body, and headers as needed.
- In request.map the left side is the API field name and the right side reads a value. $.query reads the tool argument named query, not the URL query string or an environment variable.
- Use request.auth: none for public operations, session for a host-supplied Bearer token, or api-key with env and header for a service key. Do not put secrets in YAML, input_schema, or mapped headers.
- GET and HEAD cannot have a body. Do not add models, dependencies, or retries without a concrete need. If an ID needs a lookup, explain it or choose the simpler starting operation; never invent an ID.
- Add output_schema only from a verified contract, not assumptions based on one sample.
- Do not create a mock server or replace fetch.
- Use only options supported by the supplied AGENTO references.

Then:
1. Explain each block: its API evidence, purpose, and what changes when it is removed or edited.
2. Produce input.json using suitable documented test values, without secrets.
3. Give the run.mjs command with the tool name and input file from the attached quick start.
4. Show the expected HTTP request and how to compare it with my direct successful request.
5. Explain completed, needs_input, and error for this test. Never automatically select or confirm.
6. List remaining manual substitutions. Do not claim the integration was tested unless it actually ran.

Ask for missing references. Generated configuration is a proposal to review, not proof of correctness.